Re: gtk-based sip client "locking up"

[Paul Pogonyshev <pogonyshev gmx net>]

Miguel Mendez wrote:
> > 1) Valgrind.  It's not easy to find memory leaks in GTK+ code because GTK+
> >    itself and especially X (it seems) both leak like mad, but reads of
> >    uninitialized memory, writes to unallocated memory and such are
> >    easily spottable with Valgrind.
>
> Could you elaborate on that? I'm not 100% sure about X (although I have
> my doubts, since I've had X running for 4-6 weeks with no problems), but
> I don't think GTK+ leaks, at least not if used properly.
>
> [...]

A few selected leaks.

==5297== 338831 bytes in 7317 blocks are still reachable in loss record 141 of 141
==5297==    at 0x4015DD3C: malloc (vg_clientfuncs.c:103)
==5297==    by 0x405D8DE9: g_malloc (gmem.c:136)
==5297==    by 0x405EA7FE: g_thread_self (gthread.c:670)
==5297==    by 0x405E933D: g_thread_init_glib (gthread.c:146)
==5297==    by 0x405B1460: g_thread_init (gthread-impl.c:377)  <-- entering GLib
==5297==    by 0x8051D23: gui_back_end_init (gui-back-end.c:59)
==5297==    by 0x8051CBD: main (quarry.c:45)
==5297==    by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)
==5297==    by 0x8051BF8: (within /home/paul/quarry/src/quarry)

==5297== 85208 bytes in 686 blocks are still reachable in loss record 138 of 141
==5297==    at 0x4015E2A9: realloc (vg_clientfuncs.c:276)
==5297==    by 0x405D8EBA: g_realloc (gmem.c:169)
==5297==    by 0x4058FAC2: type_node_any_new_W (gtype.c:403)
==5297==    by 0x4058FD85: type_node_new_W (gtype.c:465)
==5297==    by 0x40594128: g_type_register_static (gtype.c:2273)
==5297==    by 0x40584E8C: g_param_type_register_static (gparam.c:1058)
==5297==    by 0x4058684C: g_param_spec_types_init (gparamspecs.c:1405)
==5297==    by 0x405971FA: g_type_init_with_debug_flags (gtype.c:3482)
==5297==    by 0x405972B1: g_type_init (gtype.c:3498)
==5297==    by 0x404811B0: gdk_parse_args (gdk.c:348)
==5297==    by 0x402E6996: gtk_parse_args (gtkmain.c:703)
==5297==    by 0x402E6E21: gtk_init_check (gtkmain.c:916)  <-- entering GTK+
==5297==    by 0x8051D44: gui_back_end_init (gui-back-end.c:64)
==5297==    by 0x8051CBD: main (quarry.c:45)
==5297==    by 0x420158D3: __libc_start_main (in /lib/i686/libc-2.2.93.so)
==5297==    by 0x8051BF8: (within /home/paul/quarry/src/quarry)

==5297== 249 bytes in 1 blocks are still reachable in loss record 70 of 141
==5297==    at 0x4015DD3C: malloc (vg_clientfuncs.c:103)
==5297==    by 0x406621FF: XGetWindowProperty (in /usr/X11R6/lib/libX11.so.6.2)  <-- entering X
==5297==    by 0x404A7CFB: gdk_x11_screen_supports_net_wm_hint (gdkevents-x11.c:2569)
==5297==    by 0x404B792D: gdk_window_focus (gdkwindow-x11.c:1696)
==5297==    by 0x403CC4F3: gtk_window_present (gtkwindow.c:5718)   <-- entering GTK+
==5297==    by 0x8052441: gtk_control_center_present (gtk-control-center.c:88)
==5297==    ...

In total I have about 1 MB of unfreed memory.  Almost all is "still reachable",
but anyway it's very difficult to search for leaks which you are responsible
for yourself when the number of loss records is over 100.

Most of this memory is only allocated once and is not really leaked.  But still
it garbles Valgrind's output.  Tracking non-freed GTK+ resources is almost
impossible because I cannot distinguish them from other loss records.  I can
only spot basic problems like when the backtrace contains [g_]malloc() called
directly from my own function.

I have some supplementary programs in my build tree which don't use GTK+/GLib.
For them I can easily reach this sort of Valgrind output:

==1037== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==1037== malloc/free: in use at exit: 0 bytes in 0 blocks.

because nothing hides my own errors.

Some years ago I used to not free memory before exiting because when a process
terminates it's effectively being "freed" anyway.  Now I free _all_ memory if
only to make spotting real leaks easier.

Paul