[Fontconfig] FontConfig memory question
mathog
mathog at caltech.edu
Thu Feb 20 00:43:48 CET 2014
On 18-Feb-2014 11:18, Behdad Esfahbod wrote:
> On 14-02-18 02:08 PM, mathog wrote:
>>
>> The reason I am whining...
>
> In this case I suggest you use gobject refcounting stuff to see if any
> Pango
> objects are kept alive and track down why that may be the case first.
> Only
> then you can look into fontconfig.
Before trying that I wanted to verify that the simplest possible GTK+
program could be "clean" in valgrind. So far, no, not even close.
I stepped _way_ back and ran valgrind on the "helloworld.c" programming
example from the gtk tutorial here:
https://developer.gnome.org/gtk-tutorial/stable/c39.html
compiled and tested with:
gcc -Wall -g helloworld.c -o helloworld `pkg-config --cflags gtk+-2.0`
`pkg-config --libs gtk+-2.0`
valgrind -v --leak-check=yes --leak-resolution=high --num-callers=45 \
--show-reachable=yes ./helloworld >/tmp/vgB.log 2>&1
# let the window open, click on the button, but perform no other actions
wc /tmp/vgB.log
25328 156434 2151734 /tmp/vgB.log
tail /tmp/vgB.log
==2606==
==2606== LEAK SUMMARY:
==2606== definitely lost: 1,024 bytes in 3 blocks
==2606== indirectly lost: 2,893 bytes in 162 blocks
==2606== possibly lost: 205,800 bytes in 1,049 blocks
==2606== still reachable: 348,720 bytes in 2,367 blocks
==2606== suppressed: 0 bytes in 0 blocks
==2606==
==2606== ERROR SUMMARY: 379 errors from 379 contexts (suppressed: 0 from
0)
==2606== ERROR SUMMARY: 379 errors from 379 contexts (suppressed: 0 from
0)
then added this, as you suggested previously in this thread:
pango_cairo_font_map_set_default (NULL);
cairo_debug_reset_static_data ();
before return(0) in main() and tested again:
tail /tmp/vgC.log
==2635==
==2635== LEAK SUMMARY:
==2635== definitely lost: 0 bytes in 0 blocks
==2635== indirectly lost: 0 bytes in 0 blocks
==2635== possibly lost: 144,696 bytes in 968 blocks
==2635== still reachable: 164,154 bytes in 2,272 blocks
==2635== suppressed: 0 bytes in 0 blocks
==2635==
==2635== ERROR SUMMARY: 324 errors from 324 contexts (suppressed: 0 from
0)
==2635== ERROR SUMMARY: 324 errors from 324 contexts (suppressed: 0 from
0)
then add
FcFini();
before return(0) in main(), and test again:
==2651==
==2651== LEAK SUMMARY:
==2651== definitely lost: 0 bytes in 0 blocks
==2651== indirectly lost: 0 bytes in 0 blocks
==2651== possibly lost: 144,432 bytes in 965 blocks
==2651== still reachable: 156,911 bytes in 2,184 blocks
==2651== suppressed: 0 bytes in 0 blocks
==2651==
==2651== ERROR SUMMARY: 321 errors from 321 contexts (suppressed: 0 from
0)
==2651== ERROR SUMMARY: 321 errors from 321 contexts (suppressed: 0 from
0)
The log file still contains an assortment of lines containing "pango"
and/or "font", but usually for a fairly small number of bytes per
record, like this:
==2684== 52 bytes in 1 blocks are still reachable in loss record 791 of
1,169
==2684== at 0x402A5E6: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2684== by 0x4666752: ??? (in
/lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2684== by 0x4666E6A: g_malloc0 (in
/lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2684== by 0x45F2965: ??? (in
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2684== by 0x45F3230: ??? (in
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2684== by 0x45F801C: g_type_register_static (in
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2684== by 0x45F85FA: g_type_register_static_simple (in
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2684== by 0x44BAF79: pango_cairo_font_get_type (in
/usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0.3000.0)
==2684== by 0x44BF0CF: pango_cairo_fc_font_get_type (in
/usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0.3000.0)
==2684== by 0x44BF19C: ??? (in
/usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0.3000.0)
==2684== by 0x44BF5A2: ??? (in
/usr/lib/i386-linux-gnu/libpangocairo-1.0.so.0.3000.0)
==2684== by 0x4C62F94: ??? (in
/usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0.3000.0)
==2684== by 0x4C63376: ??? (in
/usr/lib/i386-linux-gnu/libpangoft2-1.0.so.0.3000.0)
==2684== by 0x47: ???
==2684==
the three biggest records do not appear to have anything to do with
fontconfig or pango:
==2684== 8,192 bytes in 1 blocks are still reachable in loss record
1,167 of 1,169
==2684== at 0x402BE68: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2684== by 0x466696A: ??? (in
/lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2684== by 0x4666E02: g_malloc (in
/lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2684== by 0x46670B2: g_malloc_n (in
/lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2684== by 0x464510B: g_quark_from_static_string (in
/lib/i386-linux-gnu/libglib-2.0.so.0.3200.4)
==2684== by 0x45FB933: g_type_init_with_debug_flags (in
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2684== by 0x45FBB0A: g_type_init (in
/usr/lib/i386-linux-gnu/libgobject-2.0.so.0.3200.4)
==2684== by 0x4184917: gtk_parse_args (in
/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10)
==2684== by 0x47474D2: (below main) (libc-start.c:226)
==2684==
==2684== 16,384 bytes in 1 blocks are still reachable in loss record
1,168 of 1,169
==2684== at 0x402A5E6: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2684== by 0x49AD9D1: XOpenDisplay (in
/usr/lib/i386-linux-gnu/libX11.so.6.3.0)
==2684== by 0x47474D2: (below main) (libc-start.c:226)
==2684==
==2684== 20,864 bytes in 1 blocks are still reachable in loss record
1,169 of 1,169
==2684== at 0x402A5E6: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==2684== by 0x4E72D8F: xcb_connect_to_fd (in
/usr/lib/i386-linux-gnu/libxcb.so.1.1.0)
==2684== by 0x4FF23B7: ???
Looked for gtk suppression files, and found this (very large) one:
http://paste.org/47748
Run the test again using it and find:
==2717== LEAK SUMMARY:
==2717== definitely lost: 0 bytes in 0 blocks
==2717== indirectly lost: 0 bytes in 0 blocks
==2717== possibly lost: 98,879 bytes in 790 blocks
==2717== still reachable: 139,599 bytes in 1,644 blocks
==2717== suppressed: 62,865 bytes in 715 blocks
==2717==
==2717== ERROR SUMMARY: 222 errors from 222 contexts (suppressed: 99
from 99)
--2717--
--2717-- used_suppression: 11 gtk_style_new
--2717-- used_suppression: 2 pango_coverage_set
--2717-- used_suppression: 67 gxk__for_screen
--2717-- used_suppression: 10 gtk_gc_get cached
--2717-- used_suppression: 353 g_type_register_static
--2717-- used_suppression: 5 pango_font_map_load_fontset
--2717-- used_suppression: 25 g_param_spec
--2717-- used_suppression: 5 gxk__for_display
--2717-- used_suppression: 12 gtk_rc_get_style
--2717-- used_suppression: 2 gtk_widget_realize 2
--2717-- used_suppression: 1 pango_ot_ruleset_new
--2717-- used_suppression: 2 gtk_container_check_resize
--2717-- used_suppression: 2 weak_pointer
--2717-- used_suppression: 48 g_type_add_interface_static
--2717-- used_suppression: 1 gdk_x11_window_set_user_time
Now one certainly could run valgrind with the generate suppression flag
and make a suppression file that suppresses all of problems logged in
helloworld.c. Problem is, I'm not at all convinced that the valgrind
messages that would be suppressed are wrong, and I suspect it would
sweep a lot of similar problems (memory not cleanly released at exit) in
a larger app like Inkscape under the carpet too.
Not surprisingly, I'm not the first person to run into this GTK+
valgrind issue:
http://www.mega-nerd.com/erikd/Blog/CodeHacking/house_of_cards.html
Thanks,
David Mathog
mathog at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech
More information about the Fontconfig
mailing list