On 18-Feb-2014 10:01, Behdad Esfahbod wrote:
On 14-02-14 08:02 PM, mathog wrote:
If pango induces fontconfig to allocate memory, but it never tells it
to
release it, then that would explain valgrind entries like this:
You are confusing still-allocated-and-reachable memory with leaks.
Gtk+
caches lots of stuff, possibly Pango contexts, which cache cairo and
fontconfig things, etc. Unless you can prove that no one above pango
is
keeping any Pango / cairo / fontconfig objects around, you can't expect
those
three pieces to fully clean up their caches.
The base issue is that when I try to look for memory problems in
Inkscape using valgrind a typical minimal run (open a file, do one
operation, close) creates a log file that looks like this (wc output):
833147 6069925 84785658 /tmp/vgB.log
It takes on the order of 5 minutes per iteration to make that file. It
is pretty much irrelevant whether the memory issues described in there
are classified as reachable, indirectly lost, possibly lost, lost, or
whatever, as the problem is that they are still logged and they are
burying (haystack) the real problems I am trying to find and fix
(needle). Valgrind lets logging for some of these classes be turned
off, but I consider memory left in any of those states to represent a
bug in Inkscape code, so turning them off defeats the purpose of using
valgrind. With the newest version of fontconfig there are only 8 issues
involving text_reassemble, and all of them are "still reachable". So no
"needle" but still some "haystack". But when the exact same test (as
far as text_reassemble) is run in its own standalone binary there are no
memory issues at all, because that only involved fontconfig, but not
freetype, pango, cairo, gtk, etc.
And yes, I do expect, or at least wish, that software that maintains its
own caches be able to clean them up again. Otherwise the situation I'm
seeing with valgrind and Inkscape is the inevitable result.
The reason I am whining is that when programs that are careful with
their memory are run in valgrind 100% of the issues valgrind notes are
bugs. So it is easy to see when new problems are introduced, because
otherwise valgrind says something like:
==1557== HEAP SUMMARY:
==1557== in use at exit: 0 bytes in 0 blocks
==1557== total heap usage: 13,102 allocs, 13,102 frees, 9,850,315
bytes allocated
==1557==
==1557== All heap blocks were freed -- no leaks are possible
In a complicated mess like what is seen with Inkscape
==2513== HEAP SUMMARY:
==2513== in use at exit: 39,160,704 bytes in 623,634 blocks
==2513== total heap usage: 3,383,415 allocs, 2,759,781 frees,
273,657,688 bytes allocated
...
==2513== LEAK SUMMARY:
==2513== definitely lost: 391,934 bytes in 10,069 blocks
==2513== indirectly lost: 1,399,796 bytes in 40,427 blocks
==2513== possibly lost: 20,984,283 bytes in 290,748 blocks
==2513== still reachable: 16,384,691 bytes in 282,390 blocks
==2513== suppressed: 0 bytes in 0 blocks
...
==2513== ERROR SUMMARY: 14582 errors from 14577 contexts (suppressed:
144154 from 601)
it is hard to even compare the output for two "identical" runs.
Especially when the program is not entirely repeatable (GUI signals may
fire in different sequences) - warnings may not come out in the same
order, let alone with the same associated addresses.
Regards,
David Mathog
mathog@xxxxxxxxxxx
Manager, Sequence Analysis Facility, Biology Division, Caltech
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
