Re: Valgrind and GTK libraries

[David NeÄas <yeti physics muni cz>]

On Tue, Jan 05, 2010 at 09:39:48AM +1100, Erik de Castro Lopo wrote:
>   ==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)
...

> 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?

If the leak is genuine, i.e. you can create arbitrary amount of leaked
but reachable memory by repeating this, I'd say there's a circular
reference between the accel label and the menu item that is not properly
broken in dispose() -- be warned that this is from half-a-minute scan of
the relevant code.

Yeti