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
