>-----Original Message-----
>From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]
>
>At 01:30 PM 3/19/2004, Mathihalli, Madhusudan wrote:
>>>-----Original Message-----
>>>From: Sander Striker [mailto:[EMAIL PROTECTED]
>>[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 "`"}
