memory leak in httpd or child process (what is a memory leak)

[Tim Writer]

Andrej Marjan <amarjan-e+AXbWqSrlAAvxtiuMwx3w at public.gmane.org> writes:

> Robert Brockway wrote:
> 
> > On Tue, 20 Dec 2005, paul sutton wrote:
> >
> >> For the benefit of those who don't know what this is could someone please
> >> explain what a memory leak is.
> 
> >
> >
> > Hi Paul.  A memory leak is when a process consumes more memory than it
> > releases.
> 
> 
> 
> That's only a partial definition of a leak -- it's perfectly reasonable for a
> process to allocate more memory than it releases, so long as it uses all that
> memory. What happens if the process tries to use more memory than is
> available is another question. :)
> 
> 
> The thing that characterizes a memory leak is that the process stops using
> some of the memory that it has allocated, but fails to release it. That's the
> leak -- the bookkeeping fails, and the process loses track of some
> memory. The memory is not being used, but since the process doesn't know
> about it anymore, it can't release it back to the operating system.

That's still not the full picture as some leaks are troublesome and some are
not. Suppose I write this:

    void silly_example(const char *s)
    {
        char *message = strdup(s);      /* strdup() allocates memory */
        printf("%s\n", message);
        /* Function returns without calling free(message). */
    }    

Clearly, whenever I call silly_example(), I leak some memory.

Now, suppose silly_example() is desinged to be called only once at program
initialization and is, in fact, called only once. Technically, I still have a
memory leak but it's bounded. The program uses more memory than is strictly
necessary but its memory usage is not growing (at least not due to this
leak).

On the other hand, consider what happens if silly_example() is called
repeatedly, every time the program services some kind of event, for example.
In this case, the program's memory usage grows without bound until it
eventually exhausts all memory or is killed (perhaps by the operating
system).

I suspect quite a few programs and libraries have initialization code that
allocates memory that is never released. While this may not be considered
"good style", it doesn't cause a problem. It's the second kind of leak that's
a problem, the kind that causes an application's memory usage to grow without
bound. Paradoxically, slow leaks are often the most difficult to track down
as the process may run for days or months before the problem is noticed.

> As Robert suggests, the bookkeeping required is quite difficult for large
> programs, which is why so many people were excited about Java and other
> languages with garbage collectors. Garbage collectors essentially automate a
> lot of this stuff, making it much harder (but by no means impossible) to
> cause a memory leak.

There are garbage collectors available for C, most notably the Boehm
Demers Weiser conservative garbage collector:

    http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Also, many C++ programs use a weak form of garbage collection known as
reference counting.

Why more C/C++ developers (including myself) don't use garbage collection
more often is a bit of a mystery.

-- 
tim writer <tim-s/rLXaiAEBtBDgjK7y7TUQ at public.gmane.org>                                  starnix inc.
647.722.5301                                      toronto, ontario, canada
http://www.starnix.com              professional linux services & products
--
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