httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathihalli, Madhusudan" <mad...@hp.com>
Subject [PATCH ?] RE: SEGV in allocator_free
Date Sat, 20 Mar 2004 02:51:41 GMT
Do we need to do the following ? I tried it - the test continued to a certain extent, only
to fail again after some time (with the same stack trace)

-Madhu


Index: core.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/core.c,v
retrieving revision 1.267
diff -u -r1.267 core.c
--- core.c      15 Mar 2004 23:08:41 -0000      1.267
+++ core.c      20 Mar 2004 02:43:12 -0000
@@ -3853,6 +3853,8 @@
          */
         apr_bucket *last_merged_bucket = NULL;
 
+        apr_int32_t eoc_received = 0;
+
         /* tail of brigade if we need another pass */
         more = NULL;
 
@@ -3867,6 +3869,7 @@
                 break;
             }
             if (AP_BUCKET_IS_EOC(e)) {
+                eoc_received = 1;
                 apr_bucket_delete(e);
             }
             else if (APR_BUCKET_IS_FLUSH(e)) {
@@ -4035,6 +4038,7 @@
          *       with the hope of concatenating with another response)
          */
         if (nbytes + flen < AP_MIN_BYTES_TO_WRITE
+            && !eoc_received
             && ((!fd && !more && !APR_BUCKET_IS_FLUSH(last_e))
                 || (APR_BUCKET_IS_EOS(last_e)
                     && c->keepalive == AP_CONN_KEEPALIVE))) {


>-----Original Message-----
>From: Mathihalli, Madhusudan 
>Sent: Friday, March 19, 2004 5:48 PM
>To: dev@httpd.apache.org
>Subject: RE: SEGV in allocator_free
>
>
>>-----Original Message-----
>>From: William A. Rowe, Jr. [mailto:wrowe@rowe-clan.net]
>>
>>At 01:30 PM 3/19/2004, Mathihalli, Madhusudan wrote:
>>>>-----Original Message-----
>>>>From: Sander Striker [mailto:striker@apache.org]
>>>[SNIP]
>>>>
>>>>allocator = 0x0, that's bad.  You didn't do a full httpd rebuild, so
>>>>there is no way of telling what pool this is.  Can you do a full
>>>>rebuild (with pool debugging enabled)?  Is this vanilla 
>httpd-2.0.48?
>>>
>>>Pretty much - with some minor fixes for HP-UX, and some SSL 
>>fixes that've gone into the 2.0.49 release.
>>>(fix mem leak and send the 'close-alert' message)
>>
>>so the mem leak fix is there?
>>
>>if the segfault reoccurs - would you validate that the vanilla 
>>2.0.48 suffered
>>the same segv?
>
>
>Here's the stack trace of the SEGV with 2.0.49:
>
>Frame 14 is apr_pool_clear and so is Frame 1 ! Is there some 
>sort of a recursion happening ?
>
>-Madhu
>
>
>Program received signal SIGSEGV, Segmentation fault.
>[Switching to thread 14 (system thread 1119673)]
>0xc000000001baaf30:0 in allocator_free 
>(allocator=0x60000000001cafb0, node=0x0)
>    at apr_pools.c:335
>335     in apr_pools.c
>(gdb) bt
>#0  0xc000000001baaf30:0 in allocator_free 
>(allocator=0x60000000001cafb0, 
>    node=0x0) at apr_pools.c:335
>#1  0xc000000001babdc0:0 in apr_pool_clear (pool=0x60000000006cf1c8)
>    at apr_pools.c:713
>#2  0x40000000000b5690:0 in core_output_filter+0x1cd0 ()
>#3  0x4000000000095630:0 in ap_pass_brigade+0x1d0 ()
>#4  0xc000000001ebb770:0 in bio_filter_out_flush+0x3a0 ()
>   from /opt/apache2.0.49/modules/mod_ssl.so
>#5  0xc000000001ebbbf0:0 in bio_filter_out_write+0x2e0 ()
>   from /opt/apache2.0.49/modules/mod_ssl.so
>#6  0xc000000001f6b0e0:0 in BIO_write+0x1a0 ()
>   from /opt/apache2.0.49/modules/mod_ssl.so
>#7  0xc000000001f44a90:0 in ssl3_send_alert+0x770 ()
>   from /opt/apache2.0.49/modules/mod_ssl.so
>#8  0xc000000001f3dd60:0 in ssl3_shutdown+0xe0 ()
>   from /opt/apache2.0.49/modules/mod_ssl.so
>#9  0xc000000001f12ee0:0 in SSL_shutdown+0xe0 ()
>   from /opt/apache2.0.49/modules/mod_ssl.so
>#10 0xc000000001eeb9e0:0 in SSL_smart_shutdown+0x60 ()
>   from /opt/apache2.0.49/modules/mod_ssl.so
>#11 0xc000000001ebe960:0 in ssl_filter_io_shutdown+0x230 ()
>   from /opt/apache2.0.49/modules/mod_ssl.so
>#12 0xc000000001ebecc0:0 in ssl_io_filter_cleanup+0xd0 ()
>---Type <return> to continue, or q <return> to quit---
>   from /opt/apache2.0.49/modules/mod_ssl.so
>#13 0xc000000001badb60:0 in run_cleanups (cref=0x6000000000224ec8)
>    at apr_pools.c:1951
>#14 0xc000000001babca0:0 in apr_pool_clear (pool=0x6000000000224ea8)
>    at apr_pools.c:693
>#15 0x400000000005c940:0 in worker_thread+0x5a0 ()
>#16 0xc000000001b9b220:0 in dummy_worker (opaque=0x60000000000be908)
>    at thread.c:88
>#17 0xc0000000000a21a0:0 in __pthread_unbound_body+0x490 ()
>   from /usr/lib/hpux64/libpthread.so.1
>(gdb) fr 1
>#1  0xc000000001babdc0:0 in apr_pool_clear (pool=0x60000000006cf1c8)
>    at apr_pools.c:713
>713     in apr_pools.c
>(gdb) p *pool
>$6 = {parent = 0x6000000000224ea8, child = 0x0, sibling = 
>0x6000000000459268, 
>  ref = 0x6000000000224eb0, cleanups = 0x0, allocator = 
>0x60000000001cafb0, 
>  subprocesses = 0x0, abort_fn = 0, user_data = 0x0, tag = 0x0, 
>  active = 0x60000000006cf1a0, self = 0x60000000006cf1a0, 
>  self_first_avail = 0x60000000006cf230 "`"}
>(gdb) fr 14
>#14 0xc000000001babca0:0 in apr_pool_clear (pool=0x6000000000224ea8)
>    at apr_pools.c:693
>693     in apr_pools.c
>(gdb) p *pool
>$8 = {parent = 0x600000000001f9f8, child = 0x0, sibling = 
>0x6000000000222e88, 
>  ref = 0x6000000000226ed8, cleanups = 0x60000000005d42a0, 
>  allocator = 0x60000000001cafb0, subprocesses = 0x0, abort_fn = 0, 
>  user_data = 0x0, tag = 0x4000000000037220 "transaction", 
>  active = 0x60000000005d01c0, self = 0x6000000000224e80, 
>  self_first_avail = 0x6000000000224f10 "`"}
>

Mime
View raw message