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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
