httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonyou, Austin" <aus...@coremetrics.com>
Subject RE: memory leak on daedalus
Date Tue, 17 Jul 2001 21:24:44 GMT
Will that cause any hanging of the child processes if that happens? In the
sense that data allocated for loopback will not be retrieved or flushed at
some point? 

-- 
Austin Gonyou
Systems Architect, CCNA
Coremetrics, Inc.
Phone: 512-796-9023
email: austin@coremetrics.com 

> -----Original Message-----
> From: Greg Ames [mailto:gregames@remulak.net]
> Sent: Tuesday, July 17, 2001 4:10 PM
> To: new-httpd@apache.org
> Subject: Re: memory leak on daedalus
> 
> 
> Greg Ames wrote:
> 
> > Digging thru the core dump from the new build, I see we are leaking
> > apr_sockaddr_t's.  They are being allocated out of the 
> pconf pool, so
> > they will never be cleaned up until the process dies
> 
> ap_mpm_pod_signal in mpm_common.c is guilty.  Every time this function
> is called by perform_idle_server_maintenance, the parent leaks another
> apr_sockaddr_t.  When the parent forks off new children, they inherit
> the bloat factor.  Setting MaxRequestsPerChild small doesn't help in
> this case; restarting the server is the only circumvention.
> 
> Here's my plan:  change the pod creation code to create a single
> apr_sockaddr_t containing the loopback address etc.  Hang it off the
> pod, and use it from there when needed in ap_mpm_pod_signal.
> 
> Greg
> 

Mime
View raw message