Bill C wrote:
> Valgrind is an excellent product, and is designed for programmer use only.
>
> It shows where unreleased memory was allocated, so one can trace each
> chunk of memory to see if it should have been released, and take
> appropriate action it your code allocated it.
That is easy when when it obviously in client code. My particular issue
is that I am absolutely sure the code I am working on (I didn't write it
btw) is leaking GTK resources. Given this code leaks 20000 blocks and the
GTK helloworld (far, far simpler) leaks 8000, how do I know which of
the 20000 leaks I can fix.
From this:
http://www.mega-nerd.com/erikd/Blog/files/sweep-valgrind.txt.gz
lets look at one specific leak record:
==12528== 27,300 bytes in 175 blocks are still reachable in loss record
11,194 of 11,196
==12528== at 0x4024C1C: malloc (vg_replace_malloc.c:195)
==12528== by 0x4B342E3: g_malloc (gmem.c:131)
==12528== by 0x4B4A418: g_slice_alloc (gslice.c:824)
==12528== by 0x4B4A714: g_slice_alloc0 (gslice.c:833)
==12528== by 0x474F8F6: g_type_create_instance (gtype.c:1654)
==12528== by 0x4734747: g_object_constructor (gobject.c:1383)
==12528== by 0x4735707: g_object_newv (gobject.c:1171)
==12528== by 0x4736589: g_object_new_valist (gobject.c:1323)
==12528== by 0x473670D: g_object_new (gobject.c:1086)
==12528== by 0x4195924: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.3)
==12528== by 0x4197833: ??? (in /usr/lib/libgtk-x11-2.0.so.0.1800.3)
==12528== by 0x4196787: gtk_menu_item_set_label (in
/usr/lib/libgtk-x11-2.0.so.0.1800.3)
==12528== by 0x4735CE3: g_object_newv (gobject.c:968)
==12528== by 0x47365F0: g_object_new_valist (gobject.c:1364)
==12528== by 0x473670D: g_object_new (gobject.c:1086)
==12528== by 0x4197347: gtk_menu_item_new_with_label (in
/usr/lib/libgtk-x11-2.0.so.0.1800.3)
==12528== by 0x808E8AA: create_proc_menu (view.c:175)
==12528== by 0x8096E2B: view_new (view.c:1167)
==12528== by 0x8097638: view_new_all (view.c:2562)
==12528== by 0x806713F: _sndfile_sample_load (file_sndfile1.c:712)
==12528== by 0x8064BAF: try_sample_load (file_dialogs.c:225)
==12528== by 0x8057FD2: initial_sample_load (main.c:73)
==12528== by 0x4B2A100: g_idle_dispatch (gmain.c:4065)
==12528== by 0x4B2BE87: g_main_context_dispatch (gmain.c:1960)
==12528== by 0x4B2F72F: g_main_context_iterate (gmain.c:2591)
==12528== by 0x4B2FB9E: g_main_loop_run (gmain.c:2799)
==12528== by 0x4185418: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.1800.3)
==12528== by 0x8057CAE: main (main.c:214)
The code uses gtk_menu_item_new_with_label() to create a submenu which gets
added to a menu which get attached to a top level window (one top level
window per open file). I would expect that the submenu gets cleaned up when
the top level window gets destroyed. Is that not the case?
> Humans can make mistakes,
Yep, humans are completely hopeless :-).
> but GTK is well tested.
I agree. The fact that GTK shows *zero* of the use-of/condition-jump on
uninitialied memory errors shows that the GTK devs have spent a lot of
time tracking down and killing all instances of that class of bugs.
> In my case, suspected errors in linux library code have always been
> errors in my own code which surface as Gnu libraries are improved.
I am a library author myself and my goal in library design has always
been to make the library difficult to mis-use. Above all I did this
to reduce the amount of work I would have to do supporting my libraries.
Admittedly my libraries are far smaller than GTK and have far simpler
goals. However, I think all library designers should have Rusty Russel's
guide on API design titled "How Do I Make This Hard to Misuse?" :
http://ozlabs.org/ ̃rusty/index.cgi/tech/2008-03-30.html
on hand whenever they are doing any API design work.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
