Perhaps this should be discussed on the serf dev list? Or an issue filed in
their tracker?
On 11/19/2012 10:09 AM, Stefan Fuhrmann wrote:
> On Mon, Nov 19, 2012 at 2:44 PM, Philip Martin <philip.martin_at_wandisco.com
> <mailto:philip.martin_at_wandisco.com>> wrote:
>
> Philip Martin <philip.martin_at_wandisco.com
> <mailto:philip.martin_at_wandisco.com>> writes:
>
> > Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com
> <mailto:stefan.fuhrmann_at_wandisco.com>> writes:
> >
> >> On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin
> >> <philip.martin_at_wandisco.com <mailto:philip.martin_at_wandisco.com>>wrote:
> >>
> >>> Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com
> <mailto:stefan.fuhrmann_at_wandisco.com>> writes:
> >>>
> >>> > As it turns out, your commit has only be the trigger but
> >>> > not the root cause.
> >>> >
> >>> > serf_trunk/allocator.c, serf_bucket_allocator_create(), line 147:
> >>> >
> >>> > /* ### this implies buckets cannot cross a fork/exec. desirable?
> >>> > *
> >>> > * ### hmm. it probably also means that buckets cannot be AROUND
> >>> > * ### during a fork/exec. the new process will try to clean them
> >>> > * ### up and figure out there are unfreed blocks...
> >>> > */
> >>> > apr_pool_cleanup_register(pool, allocator,
> >>> > allocator_cleanup, allocator_cleanup);
> >>> >
> >>> > Since we fork() for hooks, we can't use hooks in ra_local
> >>> > while there is an open serf connection. Otherwise, we get
> >>> > into trouble with pool cleanups:
> >>>
> >>> Does it ever make sense for the child process to run that handler? Is
> >>> that to allow a parent process to allocate a serf connection and then
> >>> fork off a child process to use the connection?
>
> If the processes were behaving like that the child cleanup handlers
> would not be involved.
>
> >>
> >> From the comments in APR/threadproc/unix/proc.c,
> >> it seems that apr_proc_create runs *all* pool cleanups
> >> in the child process to clean up duplicated file handles
> >> and such.
> >
> > apr_proc_create runs the child cleanup handlers. Note that two handlers
> > are passed to _register, one for the parent one for the child. I'm
> > asking why serf installs a child handler rather than passing
> > apr_pool_cleanup_null.
>
> The cleanup handler is just releasing memory via apr_allocator_free. I
> see no reason for it to be installed as a child cleanup handler.
>
>
> Simply patching serf fixes the problem for me.
>
> -- Stefan^2.
>
> [[[
> Index: buckets/allocator.c
> ===================================================================
> --- buckets/allocator.c (revision 1685)
> +++ buckets/allocator.c (working copy)
> @@ -151,7 +151,7 @@
> * ### up and figure out there are unfreed blocks...
> */
> apr_pool_cleanup_register(pool, allocator,
> - allocator_cleanup, allocator_cleanup);
> + allocator_cleanup, apr_pool_cleanup_null);
>
> return allocator;
> }
> ]]]
>
> --
> Certified & Supported Apache Subversion Downloads:
> /
>
> http://www.wandisco.com/subversion/download
>
> /
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-11-29 17:52:10 CET