what are virtual memory leaks?

Greg Hunt hunt at dg-rtp.rtp.dg.com
Fri Mar 15 00:49:38 AEST 1991


In article <1991Mar13.233628.13886 at solo.csci.unt.edu>, gene at ponder.csci.unt.edu (Gene De Lisa) writes:
> 
> The subject says it. anyone know?

A memory leak is when you allocate some piece of memory and then never
free it (and you've usually lost the pointer to it so you can't free
it).  They're solved by ensuring that you free any memory you allocate
after you are finished using it.

One common place they happen is in error handling.  Say you have a
function that allocates some memory, and then starts doing something
that returns an error (like a system call maybe).  The code then
returns that error to the caller.  Fine.  But wait - you never freed
the memory, and since the pointer to it was in a local variable in a
function that's already returned, the pointer has been lost, and the
memory will forever remain allocated.  The general rule to follow is
to release any allocated resources (memory (by freeing it), file
channels (by closing them), etc.) before you handle errors, if those
resources can't be used after the error occurs.

If memory leaks occur in user programs, they'll end up chewing up lots
of virtual memory, possibly causing the system to start swapping if it
gets excessive.  However, when the process dies, of course, the memory
is all deallocated by the system as it tears down the process.

The worse situation is when they occur in the kernel.  There, they can
also cause the system to start swapping, or much worse, actually use
up physical memory (i.e., it is allocating wired memory).  If all of
the physical memory gets used up, there's no telling what will happen.
The system may just run slow as a dog, it might hang, and it might
panic.  The only way to clear memory leaks in the kernel is to reboot
the system.

Hope this helps.

-- 
Greg Hunt                        Internet: hunt at dg-rtp.rtp.dg.com
DG/UX Kernel Development         UUCP:     {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC, USA  These opinions are mine, not DG's.



More information about the Comp.unix.questions mailing list