Re: valgrind memcheck shows gtk-hello leak memories.

["David Necas (Yeti)" <yeti physics muni cz>]

On Mon, Nov 21, 2005 at 11:38:27PM -0500, Allin Cottrell wrote:
> On Tue, 22 Nov 2005, sigsegv11 wrote:
>
> >     I test a very simple gtk program from the gtk-2.0 
> > tutor(http://www.gtk.org/tutorial/x364.html) using valgrind, and 
> > it reports the program leak memories. Is it a gtk's problem(really 
> > have some memory leaks) or a valgrind's BUG?
>
> Probably neither.  To get good results with glib when using valgrind 
> (I think this is still good info), you should configure your glib 
> build using the flag
>
> --enable-gc-friendly

If you mean more memory leaks by good results, then I agree.
This option makes GLib to wipe out zombie pointers in
logically unused memory -- like GList items waiting for
recycling -- allowing valgrind to detect the memory they
pointed to is not actually reachable.

But I don't understand how --enable-gc-friendly could make
valgrind report *less* memory leaks.  I use it with
gc-unfriendly GLib and Gtk+ regularly and the leaks it finds
are real.

Instead, I'd suggest to compile GLib with -g and not to strip
it and to use --num-callers=20 or something like that to see
where the problem is (gtype.c, type_node_any_new_W()):

  node = g_malloc0 (node_size);
  if (!pnode)                                         /* offset fundamental types */
    {
      node = G_STRUCT_MEMBER_P (node, SIZEOF_FUNDAMENTAL_INFO);
      ...

Well, some people might not call that a leak because the
type info for fundamental types is never freed anyway, but
it's clear node is lost and can't be freed any more (except
by some dirty code that calculates the original pointer
again).

Then you can create a suppression and add it to your
favourite Gtk+ suppression list...

Yeti


--
That's enough.