You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Sunitha Kumar <su...@cisco.com> on 2001/10/25 04:04:07 UTC

track memory leaks in apache.

Wanted to find out if there was any thread or documentation which speak
about this.
Also, the apache documentation refers to an alloc.c file. Where is this?

And, what are the tools that people have used for tracking leaks,
Efence, zmalloc, dmalloc, purify?

thanks,

--
Sunitha Kumar
http://www.cisco.com




Re: track memory leaks in apache.

Posted by Sunitha Kumar <su...@cisco.com>.
Aaron,

Thanks much for the response. What we see here, is malloc_block is being
called repetitively.
is there some way to determine which blocks are not being released?

thanks,





Aaron Bannert wrote:

> On Wed, Oct 24, 2001 at 07:04:07PM -0700, Sunitha Kumar wrote:
> > Wanted to find out if there was any thread or documentation which speak
> > about this.
> > Also, the apache documentation refers to an alloc.c file. Where is this?
> >
> > And, what are the tools that people have used for tracking leaks,
> > Efence, zmalloc, dmalloc, purify?
>
> That's actually a difficult question to answer with Apache. Because it
> uses pools almost exclusively (there are some places that use malloc,
> but they are special cases) it usually becomes obvious very quickly
> if there is a memory leak problem. Pools, if you are not familiar with
> them, basicly allow us to "checkpoint" memory de-allocations at certain
> points in our code, instead of having to call free() for every malloc().
> This gives us a couple of benefits: 1) memory management overhead is
> dramatically reduced (O(n) free() calls vs O(1), plus free-list management
> overhead with increased fragmentation), and 2) third-party modules that
> use pools can perform safe memory allocations and don't have to worry
> about cleaning up.
>
> It is still possible for memory leaks to occur, but the likelyhood of a
> slow leak is IMO reduced with the use of pools.
>
> Are you having a specific problem that we might address?
>
> -aaron

--
Sunitha Kumar
http://www.cisco.com




Re: track memory leaks in apache.

Posted by Aaron Bannert <aa...@clove.org>.
On Wed, Oct 24, 2001 at 07:04:07PM -0700, Sunitha Kumar wrote:
> Wanted to find out if there was any thread or documentation which speak
> about this.
> Also, the apache documentation refers to an alloc.c file. Where is this?
> 
> And, what are the tools that people have used for tracking leaks,
> Efence, zmalloc, dmalloc, purify?

That's actually a difficult question to answer with Apache. Because it
uses pools almost exclusively (there are some places that use malloc,
but they are special cases) it usually becomes obvious very quickly
if there is a memory leak problem. Pools, if you are not familiar with
them, basicly allow us to "checkpoint" memory de-allocations at certain
points in our code, instead of having to call free() for every malloc().
This gives us a couple of benefits: 1) memory management overhead is
dramatically reduced (O(n) free() calls vs O(1), plus free-list management
overhead with increased fragmentation), and 2) third-party modules that
use pools can perform safe memory allocations and don't have to worry
about cleaning up.

It is still possible for memory leaks to occur, but the likelyhood of a
slow leak is IMO reduced with the use of pools.


Are you having a specific problem that we might address?

-aaron

Re: track memory leaks in apache.

Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: "Cliff Woolley" <cl...@yahoo.com>
Sent: Thursday, October 25, 2001 11:08 AM


> On Wed, 24 Oct 2001, Sunitha Kumar wrote:
> 
> > And, what are the tools that people have used for tracking leaks,
> > Efence, zmalloc, dmalloc, purify?
> 
> Various people have used at least efence and purify, maybe others.  But
> the whole point of the pools system is that it's very unlikely to get true
> memory leaks.  Sometimes we have a resource (file handle, socket, etc)
> live longer than we wanted, and we consider that a leak, but you won't
> find that kind of thing with efence and I doubt you'd find it with purify
> or any of the others either.

Use NuMega's tools here (SoftIce, etc) ... it's rather funny when Apache 
fails to leave any dangling resources, and yet you uncover a dozen odd bugs
in the clib (MS's msvcrt in my case.)

Proves Apache is a rather useful clib stress test ;)

Bill


Re: track memory leaks in apache.

Posted by Cliff Woolley <cl...@yahoo.com>.
On Wed, 24 Oct 2001, Sunitha Kumar wrote:

> Wanted to find out if there was any thread or documentation which
> speak about this. Also, the apache documentation refers to an alloc.c
> file. Where is this?

You're looking at outdated documentation.  1.3's alloc.c now lives in APR
under memory/unix/apr_pools.c.

> And, what are the tools that people have used for tracking leaks,
> Efence, zmalloc, dmalloc, purify?

Various people have used at least efence and purify, maybe others.  But
the whole point of the pools system is that it's very unlikely to get true
memory leaks.  Sometimes we have a resource (file handle, socket, etc)
live longer than we wanted, and we consider that a leak, but you won't
find that kind of thing with efence and I doubt you'd find it with purify
or any of the others either.

--Cliff

--------------------------------------------------------------
   Cliff Woolley
   cliffwoolley@yahoo.com
   Charlottesville, VA