memory profiling (was calling g_malloc & co via a vtable)

[Darin Adler <darin eazel com>]

on 10/4/00 7:39 AM, Havoc Pennington at hp redhat com wrote:

> Or better, put in a more useful profiler (well, it will already be
> more useful if you don't have to rebuild glib to use it...)

There's a simple profiler that we are using for Nautilus development in the
eazel-tools module, called leak-checker. In the last couple of weeks I've
found and fixed many leaks with it. I think Ettore has tried it out on
Evolution too.

> Yep. Or as Tim suggested, have a setting for low-memory apps where
> GList, etc. don't use the mem chunks.

For the leak checker, I done what I can without modifying glib to make all
the code use g_malloc and g_free directly for profiling purposes instead of
using local allocation schemes. I've been able to redirect the mem. chunk
API to use malloc and free directly using the symbol override techniques
that are also the basis of how the leak checker implementation catches
malloc and free. But code that recycles blocks locally and doesn't call any
"extern" API to do that has thwarted me in classes like GNode and GTree.

I'd be happy to supply a patch that makes this work much better.

Also, there are lots of things in glib, gtk, and gnome-libs that allocate
one-time items and don't free on exit. Given the approach of the leak
checker, each of these has to be identified by function name so it can be
ignored.

What do the Gtk+ maintainers think about a policy where we provide the
additional code to free these data structures on exit, using g_atexit? I'd
be happy to supply patches for this as well at some point.

    -- Darin