httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Varju <>
Subject RE: Memory leak on Windows [Bugzilla #11427]
Date Tue, 17 Dec 2002 21:21:06 GMT
Hi Bill,

Thank you for looking at this.

I've just grabbed the httpd-2.0, apr, apr-util, and apr-iconv modules from
CVS (-rHEAD).  With the same configuration file as I was using in 2.0.43,
I can still reproduce the problem.

I then added 'KeepAlive off' to my configuration file.  With this setting,
the problem continues to display itself on my server.  With 'KeepAlive on'
and 'MaxKeepAliveRequests 10' in my configuration file, again the problem

I am running two different tests to reproduce this, although they may not
be related.  In the first test, I have a client machine running
SilkPerformer which opens up several parallel requests to the server.  In
the second test, I use Internet Explorer and hold down the F5 key for a
few seconds straight .. I think this triggers the client abort code inside

Any other suggestions?  My plan now is to walk through all the memory
allocations in the call stack in the hopes that I find something using a
pool that doesn't get released.  I'm definitely not looking forward to


On Tue, 17 Dec 2002, Bill Stoddard wrote:

> I am running 2.0.44-dev (latest snapshot in CVS from just a few minutes ago) and
> I'm not able to recreate this problem. Have you tried the latest version of 2.0
> (CVS HEAD)?  Just for fun, try disabling keep-alive connections or set
> MaxKeepAliveRequests to a small value (maybe from the default of 100 to 10) and
> report back the results.
> Bill
> >
> > Hi,
> >
> > I'm still trying to track the cause of this problem down, and I'm hoping
> > somebody around here can help me.
> >
> > To summarize, I'm seeing Apache's memory footprint grow abnormally large
> > on Windows when using CGIs.  The size of the growth seems to be
> > proportional to the amount of data printed to stdout from the CGI.
> >
> > Some sample data:
> >  - With 16 threads and 1 meg sent to stdout, combined physical and virtual
> >    memory reaches about 70 megs after hammering the server for several
> >    minutes
> >  - If I increase the amount of stdout data to 2 megs, the process grows to
> >    about 130 megs within another few minutes.
> >
> > I've spent the last few days reviewing the code, and I'm a bit confused
> > about the mpm_winnt pool cleanup code.  I haven't spent a lot of time
> > reading the code in the past, so there's a good chance that I've just
> > missed something.  As far as I can tell, ap_read_request() creates the
> > request pool, but nothing explicitly cleans it up.  Instead, it looks like
> > mpm_recycle_completion_context() clears the ptrans pool the next time the
> > thread handles a request.  While this seems funny to me, I don't see why
> > some of the memory would fail to be released.
> >
> > I've tried to simplify my httpd.conf file to reduce the test case:
> >
> >   ServerRoot c:/varju/webct/webct/server
> >   ThreadsPerChild 16
> >   LoadModule cgi_module modules/
> >   LoadModule alias_module modules/
> >   Listen 80
> >   ScriptAlias / c:/varju/webct/webct/webct/generic/public/
> >
> > Can anybody offer me suggestions of where to look next?
> >
> > Thanks,
> > Alex.

View raw message