apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@covalent.net>
Subject Re: segv after client closes connection
Date Thu, 15 Nov 2001 05:12:37 GMT

Okay, I found a patch that solves the problem for me.  Cliff, please test and
let me know if it fixes your problem.  I am also not sure that I like this
patch.  But, I will post it here and let people comment.

Index: memory/unix/apr_pools.c
===================================================================
RCS file: /home/cvs/apr/memory/unix/apr_pools.c,v
retrieving revision 1.115
diff -u -d -b -w -u -r1.115 apr_pools.c
--- memory/unix/apr_pools.c	2001/10/29 14:54:19	1.115
+++ memory/unix/apr_pools.c	2001/11/15 04:52:01
@@ -939,15 +939,15 @@
  */
 APR_DECLARE(void) apr_pool_clear(apr_pool_t *a)
 {
+    /* run cleanups and free any subprocesses. */
+    run_cleanups(a->cleanups);
+    a->cleanups = NULL;
     /* free the subpools. we can just loop -- the subpools will detach
        themselve from us, so this is easy. */
     while (a->sub_pools) {
 	apr_pool_destroy(a->sub_pools);
     }
 
-    /* run cleanups and free any subprocesses. */
-    run_cleanups(a->cleanups);
-    a->cleanups = NULL;
     free_proc_chain(a->subprocesses);
     a->subprocesses = NULL;
 

Ryan

On Wednesday 14 November 2001 08:53 pm, Cliff Woolley wrote:
> On Wed, 14 Nov 2001, Ryan Bloom wrote:
> > Essentially, what is happening, is that we register a cleanup on the
> > connection pool to call lingering_close.  We have a sub-pool from the
> > connection pool in the core_output_filter.  The bug happens anytime we
> > have not written all of the data when we call lingering_close.  Because
> > we clear all sub-pools before calling the cleanups, we end up calling
> > into the core_output_filter, looking for a sub-pool that doesn't exist
> > anymore.
>
> Yeah, that's what I reported two days ago.  ;)
>
> > I'm still looking for solutions to the bug.
>
> There probably needs to be some way for the core_output_filter to know its
> ctx is no longer valid.  Maybe have the core_output_filter register a
> cleanup on the subpool that will NULL out the ctx->subpool pointer when
> the subpool goes away?
>
> > > telnet localhost 80
> > > CONNECT www.google.com HTTP/1.0
>
> FYI, you'll also run into this bug if you have the latest LWP perl package
> installed when running test #2 of limits.t from the test suite.

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------

Mime
View raw message