On Fri, Jun 17, 2011 at 9:42 AM, Joe Orton <[email protected]> wrote: > mod_slotmem_shm is creating a subpool of pconf ("gpool") in the > pre_config hook. It then hangs a cleanup off pconf in the post_config > hook, which uses something with the structures in "gpool". > > This doesn't work (and segfaults with APR pool debugging) because the > gpool contents are invalidated by the time the cleanup runs. > > Patch below moves the cleanup to the "gpool", which avoids the problem > and doesn't seem to break anything else, but the subpool is never > cleared or destroyed... so could we just remove the subpool altogether? > (Is there is an unfullfilled intention to bound memory use across > generations here perhaps?) > > Index: mod_slotmem_shm.c > =================================================================== > --- mod_slotmem_shm.c (revision 1136832) > +++ mod_slotmem_shm.c (working copy) > @@ -643,7 +643,7 @@ > static int post_config(apr_pool_t *p, apr_pool_t *plog, apr_pool_t *ptemp, > server_rec *s) > { > - slotmem_shm_initialize_cleanup(p); > + slotmem_shm_initialize_cleanup(gpool); > return OK; > } >
I'm confused about a very basic issue... Hopefully something about the following is wrong: * Worker threads in gracefully exiting processes can't access the shared memory if it is being destroyed with pconf. * The shared memory has to be destroyed explicitly at some point or there is a leak. * A DSO can't register a cleanup with any pool which lives longer than pconf because the cleanup function itself will be unloaded and loaded again at a different address across restart before that registered cleanup runs.
