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