So why are we setting up a socket connection in ap_mpm_pod_signal() in the
first place? To me it seems that is uncalled for.
I have noticed that the apr_poll_socket_add(pollset, pod->pod_in,...) is not
being done in worker_thread() ! Any specific reason why?
I have implemented apr_poll_socket_add(pollset, pod->pod_in, APR_POLLIN),
and removed the socket call from ap_mpm_pod_signal(), and preliminary sanity
checks show that things are working fine.
So is there something that I am missing? Must be, because opening a socket
connection to force a select call to succeed is not a bright solution IMO.
M
> -----Original Message-----
> From: Greg Ames [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 17, 2001 2: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
>
