Re: [gtk-list] GLib is lying to me? :)

[Havoc Pennington <hp redhat com>]

On Sun, 25 Jul 1999, David Allen wrote:
> 
> g_mem_profile() tells me I have some serious problems.  I've checked the code
> thoroughly, and I can't find where the leak is happening - but this is why
> I think that glib is lying to me.
>

You may just be seeing the memory glib/gtk caches and doesn't free. 
 
> AFTER I destroy the widget, I call g_mem_profile and get an idea of the 
> outstanding memory when the application exits.  Say this is X.  Then I go
> back and recompile with a few extra g_free calls, g_freeing all of the 
> widgets I just destroyed - glib complains that it's freeing memory that's
> already been freed and so on, but when g_mem_profile runs, it gives me
> X-500 outstanding bytes - glib said that it was freeing memory that had already
> been freed, (hopefully through gtk_widget_destroy) and I end up with less 
> memory outstanding.
> 

It's wrong to call g_free() on the widget structs. If that frees up memory
it's just some weird implementation detail.

> What's going on with that?  And what strategies do people use for memory 
> management in GTK+ programs, since although I've read the docs I obviously
> don't know much about it.  Any help would be appreciated.  (Thanks to havoc
> for the earlier tips about env vars with glib memory)
> 

If you gtk_widget_destroy() widgets, just assume their memory is freed. If
it isn't it's a Gtk bug and not your problem (unless you want to delve
into Gtk internals). 

To track memory leaks you really need a specialized tool; ccmalloc sort of
works, Purify/Insure++ are proprietary apps that are a bit more powerful.

Havoc