[9fans] leak

[9fans] leak

[Steve Simon]

Used leak(1) in anger for the first time,
major kudos to its author.

-Steve

Re: [9fans] leak

[Sape Mullender]

> Used leak(1) in anger for the first time,
> major kudos to its author.

Our resident genius Russ.

Leak: can't live without it.

Re: [9fans] leak

[Axel Belinfante]

> > Used leak(1) in anger for the first time,
> > major kudos to its author.
> 
> Our resident genius Russ.
> 
> Leak: can't live without it.

having been using it a bit today I'm
wondering if I'm missing something.

Is there an easy way to record (get at) the whole
function call stack at the moment of allocation
(e.g. like purify gives)?
Right now I just see the immediate caller of malloc
which may be a bit too limited (cumbersome to work with)
at times.

I've been adding 'setmalloctag(x, getcallerpc(&foo))'
by hand in the source to slowly get to the caller
of the caller of (the caller of ...) of malloc
and could imagine there is a better way... ?

Axel. - nevertheless, found+plugged the leaks :-)

Re: [9fans] leak

[Russ Cox]

> Is there an easy way to record (get at) the whole
> function call stack at the moment of allocation
> (e.g. like purify gives)?
> Right now I just see the immediate caller of malloc
> which may be a bit too limited (cumbersome to work with)
> at times.

No, there isn't a way to get at that.  Malloc only saves
the caller of malloc and realloc.

> I've been adding 'setmalloctag(x, getcallerpc(&foo))'
> by hand in the source to slowly get to the caller
> of the caller of (the caller of ...) of malloc
> and could imagine there is a better way... ?

That's what I use.  If you allocate something and return it
to your caller and he has the responsibility to free it,
then call setmalloctag() to push that responsibility
onto him.

Or just think really hard.

Russ

Re: [9fans] leak

[Charles Forsyth]

> Is there an easy way to record (get at) the whole
> function call stack at the moment of allocation
> (e.g. like purify gives)?

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.

Re: [9fans] leak

[Axel Belinfante]

> > I've been adding 'setmalloctag(x, getcallerpc(&foo))'
> > by hand in the source to slowly get to the caller
> > of the caller of (the caller of ...) of malloc
> > and could imagine there is a better way... ?
> 
> That's what I use.  If you allocate something and return it
> to your caller and he has the responsibility to free it,
> then call setmalloctag() to push that responsibility
> onto him.

ok. unfortunately this was not in my own code,
but in libsec (mostly x509.c).
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?

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


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.


Charles said:
> 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)?


Axel.

Re: [9fans] leak

[Russ Cox]

> 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