Detecting Memory Leaks

[Josh Pollak]

As someone else said on this list, its possible you don't have a memory 
leak, but rather the program is allocating memory and just not 
deallocating it until much later. Also, as they said the memory might 
not be returned to the OS just because you deallocated it. You might 
want to see if mpatrol or some other package can generate a table of 
mallocs and frees and their times. Then you could plot these on a 
scatter plot. I wonder if perhaps you have a pattern of generally 
allocating memory but don't deallocate it until the end of execution.

Do you use std::vector or other containers, STL or otherwise? Its 
possible they at times grow large, and then never shrink again. 
Remember that std::vector doubles in size every time it runs out of 
memory, but I don't think it ever (automatically) shrinks back down by 
1/2 when it can.

-Josh

P.S. CC:'d to the list as well.


On Jul 15, 2004, at 5:38 PM, Samuel Donham wrote:

> Thanks Josh for the response,
> I forgot to specify the language, but yes, it's written in C++ with one
> hideous C/C++ API.  mpatrol eh?  I'll take a look at that.  As for
> resetting the app every 30 days (that's what I would have done!), it's 
> not
> really an option.  This app is what controls your telephone and cell 
> phone
> (if you have Verizon or AT&T).  Resetting the app takes a few seconds 
> and
> those few seconds of downtime result in thousands of dropped calls.
>
> Thanks again Josh,
> -sam
>
>
>
>> Assuming this is a C/C++ application, have you tried debugging with
>> mpatrol or electric fence? If your application runs for many days on
>> end, perhaps you can figure out a way to exercise it more than normal,
>> in order to simulate an extended period of use. After running with
>> mpatrol for a while, it should output a log file detailing all of your
>> new's and deletes (or malloc / frees), which you can then begin to 
>> hunt
>> down.
>>
>> Quick hack: Schedule your application to restart ever 30 days. That
>> should free your ram, but its a dirty hack.
>>
>> -Josh
>>
>> On Jul 15, 2004, at 4:01 PM, Samuel Donham 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.
>>> -sam
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss mailing list
>>> Discuss at blu.org
>>> http://www.blu.org/mailman/listinfo/discuss
>
>
>