GLib is lying to me? :)

[David Allen <opop erols com>]

I'm in the process of trying to get rid of some evil memory problems with
an application, and it goes something like this...

I'm using g_mem_profile() like crazy because it helps quite a bit.  Now I've
been told that when you call gtk_widget_destroy on a widget, not only does
it destroy AND free the memory for that widget, but it frees the memory and
destroys all the widgets underneath it (aka containers returned by other 
functions that were packed into the widget you destroy, etc)

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.

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.

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)

-- 
David Allen
http://opop.nols.com/
----------------------------------------
Elevators smell different to midgets.