Re: [gtk-list] GLib is lying to me? :)
- From: Havoc Pennington <hp redhat com>
- To: David Allen <opop erols com>
- cc: GTK+ List <gtk-list redhat com>
- Subject: Re: [gtk-list] GLib is lying to me? :)
- Date: Mon, 26 Jul 1999 11:52:04 -0700 (PDT)
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.
] [Thread Prev