mod_slotmem_shm pool handling

[Joe Orton <jo...@redhat.com>]

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;
 }
 

Re: mod_slotmem_shm pool handling

[Jeff Trawick <tr...@gmail.com>]

On Fri, Jun 17, 2011 at 9:42 AM, Joe Orton <jo...@redhat.com> 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.

Re: mod_slotmem_shm pool handling

[Jim Jagielski <ji...@jaguNET.com>]

On Jun 17, 2011, at 9:42 AM, Joe Orton 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?)
> 

The latter... but for now, removing the subpool and just using
pconf makes sense.