On Mon, Jan 04, 2010 at 02:56:44PM -0800, Dan Kegel wrote: > Erik de Castro Lopo <mle+...@mega-nerd.com> 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) > > Say no more! We see that tons in chromium's valgrind runs, too. > See http://crbug.com/16583 > I added a suppression for it to > http://src.chromium.org/cgi-bin/gitweb.cgi?p=chromium.git;a=blob_plain;f=tools/valgrind/memcheck/suppressions.txt > some time ago. > > Searching the web finds a few other reports of this particular leak.
Please note this is not a specific leak. Almost every GObject construction goes exactly the same code path (the exceptions are direct calls to g_object_newv() that won't show g_object_new_valist() and g_object_new()). So every time an object is leaked you get this trace. To really identify a specific leak you have to include more stack frames. Yeti _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
