Kurt Miller <[EMAIL PROTECTED]> and others write:
> Date: Thu, 30 Mar 2006 14:01:55 -0500
> From: Kurt Miller <[EMAIL PROTECTED]>
> Subject: Re: How to find memory leak in library/OS?
> In-reply-to: <[EMAIL PROTECTED]>
> To: Claus Assmann <[EMAIL PROTECTED]>
> Cc: misc@openbsd.org
> Reply-to: [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
>
> On Thursday 30 March 2006 1:25 pm, Claus Assmann wrote:
> > On Thu, Mar 30, 2006, Ted Unangst wrote:
> >
> > > particular to pthreads, if you are using mutexes or somesuch on the
> > > stack, you will leak memory. (the lock on the stack is just a
> > > pointer, it gets allocated on first use).
> >
> > All mutexes are part of structures that are allocated via malloc().
> > Would those leak memory too (even if pthread_mutex_destroy() is
> > called)? The application (it's the sendmail X address resolver)
> > uses a new mutex/condition variable for every request in the test
> > that triggers the leaks.
> >
> > Thanks for your answer!
>
> I recently went through a similar exercise looking for
> leaks in the jvm thread creation and destruction code.
> The process is simple but tedious. Build a debug version
> of libc, libpthread and your application. Put a break
> point on malloc, realloc & free. When malloc and realloc
> are hit, do the finish gdb command and note the returned
> address on a pad and where it was called from. When free is
> called cross off the matching address from the list. Whatever
> is left is the source of your leak.
>
> There are things you could do help the process along, like
> using gdb's 'commands' feature. If you suspect the pthreads
> library is leaking you could place break points at the
> malloc / realloc / free calls that your application hits in
> pthreads (ie break at the calls to malloc in the pthread code,
> not at malloc itself).
>
> -Kurt
This tedious book-keeping process is exactly the thing computers are
supposed to be good at doing. I've had a special version of malloc
that I've used for years which does this and a few other tricks. It's
not exactly elegant, because it requires relinking and usually additional
hooks in the application to take full advantage of the leak detection,
but when all else fails, I find it worth the trouble. I had forgotten it
had pthread locking logic - it might even be thread safe:
/afs/umich.edu/group/itd/build/mdw/xmalloc/src/
No real documentation, sorry.
-Marcus Watts
