Detecting Memory Leaks -- the right solution

[gaf at blu.org (Jerry Feldman)]

On Fri, 16 Jul 2004 17:40:50 UTC
John Chambers <jc at trillian.mit.edu> wrote:

> I've done this in a number of programs, and found  that  there's  one
> big  gotcha:  If  you call any library routine that calls malloc, the
> program starts shooting itself in the foot as two different  routines
> attempt  to  allocate the same memory.  So you have to make sure that
> nothing anywhere calls malloc.  (Hint: the nm program  can  tell  you
> whether malloc is called, and if so, who calls it.)
Actually, the keyword is to preempt malloc(3) and friends. if you do it
correctly, there should be no problem. Theoretically, your version of
malloc should preempt the library version causing all calls to malloc to
go to your malloc. The key is that yor malloc (and friends) must not
call the library malloc at all, but to be independent. One of the tests
we have in Purify was just this so that we could determine if Purify was
able to properly intercept your homegrown malloc. 

But, even if you do not successfully preempt malloc in the system run
time libraries, the glibc malloc is still maintaining a separate
freelist. But, the whole key to this is to look at memory allocations
occuring in library code. Purify could instrument the libraries on some
platforms, but I'm not sure that valgrind can. 


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.blu.org/pipermail/discuss/attachments/20040716/c766a86b/attachment.sig>