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