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@xxxxxxxxxxx
Manager, Sequence Analysis Facility, Biology Division, Caltech
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig
