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.mar...@wandisco.com > <mailto:philip.mar...@wandisco.com>> wrote: > > Philip Martin <philip.mar...@wandisco.com > <mailto:philip.mar...@wandisco.com>> writes: > > > Stefan Fuhrmann <stefan.fuhrm...@wandisco.com > <mailto:stefan.fuhrm...@wandisco.com>> writes: > > > >> On Mon, Nov 19, 2012 at 12:24 PM, Philip Martin > >> <philip.mar...@wandisco.com <mailto:philip.mar...@wandisco.com>>wrote: > >> > >>> Stefan Fuhrmann <stefan.fuhrm...@wandisco.com > <mailto:stefan.fuhrm...@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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
