httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gonyou, Austin" <>
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

> -----Original Message-----
> From: Greg Ames []
> Sent: Tuesday, July 17, 2001 4:10 PM
> To:
> 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

View raw message