Re: Valgrind and GTK libraries

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

On Mon, Jan 04, 2010 at 02:56:44PM -0800, Dan Kegel wrote:
> Erik de Castro Lopo <mle+gtk 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