Re: Memory leak

[jw schultz]

On Mon, Aug 26, 2002 at 03:29:17PM -0400, Richard B. Johnson wrote:
> On Mon, 26 Aug 2002, Aleksandar Kacanski wrote:
> 
> > Hello,
> > I am running 2.4.18-3 version of the kernel on smp dual
> > processor and 1GB of RAM. My memory usage is increasing and
> > I can't find what exactly is eating memory. Top and proc
> > are reporting increases, but I would like to know of a
> > better way of tracing usage of memory and possible leak in
> > application(s).
> > 
> > Please reply to [e-mail]
> > thanks                Sasha
> > 
> > 
> 
> Applications that use malloc() and friends, get more memory from
> the kernel by resetting the break address. It's called "morecore()".
> You can put a procedure, perhaps off SIGALRM, that periodically
> checks the break address and writes it to a log. Applications
> that end up with an ever-increasing break address have memory
> leaks. Note that the break address is almost never set back.
> This is not an error; malloc() assumes that if you used a lot
> of memory once, you'll probably use it again. Check out sbrk()
> and brk() in the man pages.

brk() isn't the only way applications get memory.  A
commonly used method of getting process memory is to mmap()
anonymous regions.  Some implementations of malloc() will
use mmap() for larger allocations.  If you use realloc() a
lot this can be particularly useful.

Releasing memory that has been allocated via brk() is
dependent on allocation order so it is seldom done.
Realloc() and co. used poorly can produce lots of
fragmentation exacerbating things.  Allocations done via
mmap() tend to be independent of one another so they can
released more readily.

If an application or library is using mmap() just watching
brk won't do much good.  Actually detecting leakage is very
difficult especially from outside the code.  It requires
tracking the modifications of all the pointers to allocated
memory.

The thing to keep in mind for the common case is that
applications that leak memory will release it on exit.
Most of the time any sizable amount of application memory is 
in disuse it will be in sizable chunks so under memory
pressure will be paged out until exit so will have minimal
impact on the system.

Having said all that i'll now echo Linus et al and tell you
that you want the system to use all of your memory.  Unused
memory is wasted memory and wasted money.  That is why
otherwise free memory is used as cache and disused memory
will be paged out so that it too can be used as cache to
speed up the system as a whole.

And much thanks to all the good, and heartless bastard,
developers who have and continue to work on improving the
paging algorithms and VM system as a whole.

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		[e-mail]

		Remember Cernan and Schmitt