[Fontconfig] FontConfig memory question

[mathog]

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 at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech