httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GUMMALAM,MOHAN (HP-Cupertino,ex2)" <mohan_gumma...@hp.com>
Subject RE: memory leak on daedalus
Date Wed, 18 Jul 2001 19:21:03 GMT
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:gregames@remulak.net]
> Sent: Tuesday, July 17, 2001 2: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