Memory leak

[Lennart Sorensen]

On Sun, Dec 11, 2005 at 12:56:41PM -0500, billt-lxSQFCZeNF4 at public.gmane.org wrote:
> Detecting it is really a matter of running the application and noticing that it is using more and more memory as time goes on. There are some compilers that try to detect it but to my knowledge there is no full proof way doing that.
> 
> Also simply because you are using more and more memory doen't mean you actually have a memory leak. For example a program I wrote kept a in memory btree structure to increase access speed. As information was looked and cached in the btree the amount of memory this app used increased. To an untrained user this looked exactly like a memory leak, but it wasn't since there was limits to the amount memory the app will use to cache the information and there was a way to retire unsed records.
> 
> Correcting it is finding the allocation error and correcting the code. Some allocation errors are so subtle that it is almost impossible to do it.
> 
> Most people faced with slow leaks will simply kill and restart the application once a day/week/month etc...

I remember using purify at university on solaris a few times.  It is
absolutely amazing for doing such things (and other array bounds checks
and such).  It appears it is now available for linux, and is only about
$8000 per license. :)

Len Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml