Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Detecting Memory Leaks -- the right solution

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>
Boston Linux and Unix user group 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: <>

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /