Detecting Memory Leaks -- the right solution

[gaf at blu.org (Jerry Feldman)]

Another way to detect memory leaks is to build your own malloc/free. I
might be a bit presumptuous, but if you build your own to preempt the
libc malloc, you might add some statistics to track all allocations and
frees. As long as you use a simple algorithm, it should not kill
performance too much. You can use mmap(2) or sbrk(2) to allocate your
pages. Then you could add a statistics interface as well as a possible
freeall function. You could use a simple doubly linked list as your free
pool and implement a first-fit or best fit algorithm. Then when freeing
up a block, you try to coalesce. Then at certain points in your code,
call the statistics package to see where you stand. 

By doing this, you have complete control over the
allocation/deallocation process, and you might find places where you are
holding on to memory in a manner that does not fit the definition of
memory leak, and may not be detectable by valgrind. 



-- 
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/c68a8300/attachment.sig>