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

[otaylor redhat com]

Darin Adler <darin eazel com> writes:

> on 10/4/00 9:41 AM, otaylor redhat com at otaylor redhat com wrote:
> 
> > Basically, using atexit is evil, because the
> > order of various atexit() calls is undefined,
> 
> Not true. The atexit functions run in the reverse order they were queued.
> I've been using it in Nautilus and it's working great.

OK, undefined is a bad word, maybe "unpredicatable". If you have
multiple libraries installing atexit() handlers...

> > because it interacts badly with fork()
> 
> Nautilus code always uses _exit in forks; I didn't understand why before
> this, but I assume this is why.
 
the current GDK atexit() function closes the X connection. If you
fork off another process, then when it calls exit() it will close
the X connection. Any sort of cleanup of resources shared between
threads will cause problems, and while pure g_free() doesn't cause
problems, I doubt we can get down to zero alloced memory without
closing shared resources.

> > etc.
> 
> I'd like to hear about the etc. I was surprised that this approach worked as
> well as it has, but it is working fine and I don't know of major drabacks.
> 
> > I'd like to get rid of the current atexit that GDK installs.
> 
> It would make my leak checker work less well.

Ummm, no it wouldn't. The current atexit cleans up very little
memory, it just basically is there to try and restore the keyboard
repeat rate. It also calls XCloseDisplay(). Which is what causes
most of the problems right now with forks.
 
> > we could probably add a call to free the free lists,
> > (g_flush_unused()) or something like that.
> >
> > We could also add some sort of gtk_uninit(), though it would be
> > a pain to get right.
> 
> That would probably work even for fans of atexit like me, since I can just
> call g_atexit (gtk_uninit).
> 
> I've done this atexit approach a lot with nautilus and gnome-vfs code and
> it's working great.

Trying to get down to zero malloced blocks on exit is just a poor
way to do leak detection. Your basically throwing away one of the
advantages of Unix (it knows how to clean up after processes properly)
for the sake of leak detection that can be done in other ways.

Yes, it is a simple technique to implement and has no false negatives, 
but other than that it is pretty artificial.

Regards,
                                        Owen