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

[Darin Adler <darin eazel com>]

on 10/4/00 1:10 PM, 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...

I won't try to keep this going beyond this, but I must say that where this
approach really *shines* is with multiple libraries installing atexit
handlers. The order of cleanup is the opposite of the order of
initialization and that has always been perfect. With explicit cleanup it's
hard to get the order right. This is analogous to the
constructors/destructors in C++ that also make it easier to get the right
amount of cleanup done in the right order.

> 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.

You mean cleanup of resources shared between processes, not threads, right?

In nautilus we cleanly shut down all the threads as part of the exiting
process. When we didn't do that in the past the executable stayed running.
Am I missing something here? We definitely close shared resources in our
atexit functions, interleaved with closing down the threads that use them.
But we don't share many resources between forked processes, it's true.

>>> 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.

Getting rid of that keyboard repeat rate thing sounds good, but it doesn't
seem to tar atexit, just a poor use of it.

> Trying to get down to zero malloced blocks on exit is just a poor
> way to do leak detection.

You are wrong. I tried the "good" ways to do leak detection, including the
memprof tool, and they didn't work well. This "poor" way to do leak
detection that Pavel Cisler developed helped me find many leaks very quickly
after a small initial investment to filter out noise caused by blocks not
deallocated on exit.

> 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.

I am not "throwing away" this advantage of Unix, which still prevents
mistakes in my code from causing problems. Also, when not leak checking I
can turn off this exit cleanup code if it has any measurable or noticeable
effect on performance.

I agree that in principle leak checking can be done well other ways, for
example Purify works well, but only on Solaris and it costs money, but I
have no leak checking tool that works well enough to use those other ways.
This "0 blocks on exit" tool is working pretty well for me. I'm judging by
results no principle.

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

It works great. Why does "artificial" matter? I don't care if my approach is
"real" or "cheating". It's helped me instantly find leaks that I couldn't
find after days with memprof.

So I guess I have my answer -- adding extra exit-time code to Gtk is *not*
something you are amenable to. Too bad for me.

    -- Darin