Re: [9fans] leak

[Russ Cox <rsc@swtch.com>]

> I submitted a patch to plug the leaks I encountered --
> should I also submit a patch for the setmalloctag's
> I added to analyse what goes on?

Please do.

> > Or just think really hard.
> 
> even with leak(1) and additional setmalloctag calls
> I already had to think hard enough to make sure
> I did (free) the right thing (at the right place).

For interactive programs, it's a bit easier.
You do something 100 times and then run leak
and look for blocks that have leaked 100, 200, etc.
times.

> Something else about leak:
> when I run it in textual mode (no option or -s)
> it doesn't report leaks.
> when I run it in graphical mode (-b) I do get
> red pieces in the picture.
> This surprises (confuses) me a bit.

I this this is a bug in aux/acidleak.  I just fixed it.

> > there was an older acid leak detection library that
> > took a snapshot of the call stack on each allocation.
> > that was useful, as you say.
> 
> (just curious)
> any particular reason this was deprecated (assuming it is)?

It had fallen into disrepair by the time I wanted to
use it.  The reason I wrote leak instead of fixing the
old acid library is that the acid library doesn't help
much with threaded programs.  It ran the program
with breakpoints at malloc and free, doing processing
as the program ran.  You can't do this once there are
multiple procs running around.  Also I wanted something
that worked even if the program had already started.

Russ