Detecting Memory Leaks

[gaf at blu.org (Jerry Feldman)]

On Thu, 15 Jul 2004 16:01:48 -0400 (EDT)
"Samuel Donham" <sam at machine15.com> wrote:

> Hi everyone,
> Normally, I wouldn't ask for help with work-related problems, but I'm
> out of ideas.  If anyone can provide a reasonable answer to this, I'm
> bringing a stack of free pizzas to the next BLU meeting.
> 
> One of my clients claims that I have a memory leak in one of our
> applications.  He claims that 'top' reports my app is slowly consuming
> more memory after running for 30 days (now 20 megs, up from 8 when it
> was first started).  Perhaps there is a memory leak, but I don't think
> 'top' is a good indicator of one ('free' would be much better).  In
> addition, I've searched high and low for the leak with no success. 
> I've also run Valgrind (http://valgrind.kde.org) on my app, with no
> report of a leak.
> 
> My question is, does anyone have any creative ideas to prove that a
> leak does NOT exist?  It's far easier to prove that one does exist
> than to prove it does not.  Knowing that the memory will likely be
> released after some time, I need to prove this but it will take months
> for the app to run in order to so.  I would like to limit the amount
> of memory the app is allowed to consume.  I've tried using 'ulimit,'
> but the app repeatedly goes over the limit (soft and hard).  Using
> '/etc/security' may work, but I'm reluctant to try for it's on a
> per-user basis, and I would like a per-process basis.
> 
> Any ideas?  What's YOUR favorite means of detecting memory leaks? 
> Lastly, what kind of pizza/soda  do you like?
> Any help would be greatly appreciated.  Thanks guys, see you at the
> next meeting.
Valgrind is an application designed specifically to locate memory leaks,
and should be able to locate it. 

Actually, the best product is Purify, but it is expensive. 

But, just because your application grows over time, that may not mean
that it has a memory leak. A memory leak is defined as memory you
allocate (eg. malloc), and then fail to free it and either the pointer
to that memory goes out of scope or is reused. 


But, it might just be the way malloc works. 
Malloc(3) allocates memory from a memory pool your program gets by using
the sbrk(2) system call (or in newer mallocs, mmap). Free(3) returns
memory back to the pool, and may never return any memory back to the
system. Theoretically, the freed memory should be coalesced so that
future calls to malloc(3) allocate previously freed blocks. Depending on
malloc's algorithms and the way your application is using memory, your
program could grow. Top is not really a good measure. 

Josh has some good ideas. Also, does your application use threads or
fork(2). Also, there could be a memory leak in a library where you do
not have any control. While Josh's idea for restarting the application
has some merit, you could possibly record all mallocs and frees, and at
various times free all memory and do a longjmp to the beginning of your
program (ugly and I don't recommend it). 
-- 
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/20040715/1a70795b/attachment.sig>