From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200509151601.j8FG12K29865@zamenhof.cs.utwente.nl>
To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu>
Subject: Re: [9fans] leak
In-reply-to: Your message of "Wed, 24 Aug 2005 14:46:47 -0400."
	<a06f3a65eaa6cde45a9234929df4c640@plan9.bell-labs.com> 
References: <a06f3a65eaa6cde45a9234929df4c640@plan9.bell-labs.com> 
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 15 Sep 2005 18:01:01 +0200
Topicbox-Message-UUID: 89fdd7c2-ead0-11e9-9d60-3106f5b1d025

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