SSL core dump with httpd-2.0 HEAD

[Blair Zajac <bl...@orcaware.com>]

I'm getting a core dump on apr/apr-util/httpd-2.0 from HEAD today
with ssl

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 8192 (LWP 6694)]
0x4013d6f7 in apr_bucket_alloc (size=48, list=0x805cb9c)
    at apr_buckets_alloc.c:127
127                 list->freelist = node->next;


(gdb) bt
#0  0x4013d6f7 in apr_bucket_alloc (size=48, list=0x805cb9c)
    at apr_buckets_alloc.c:127
#1  0x4013bfba in apr_bucket_transient_create (
    buf=0xe9000005 <Address 0xe9000005 out of bounds>, length=3909091333,
    list=0x30) at apr_buckets_simple.c:151
#2  0x4031a537 in bio_filter_out_flush (bio=0xe9000005) at ssl_engine_io.c:174
#3  0x4031a77f in bio_filter_out_ctrl (bio=0x805cb9c, cmd=-385875963,
    num=-2816, ptr=0x0) at ssl_engine_io.c:297
#4  0x400bb4e2 in BIO_ctrl () from /lib/libcrypto.so.2
#5  0x400be5aa in buffer_ctrl () from /lib/libcrypto.so.2
#6  0x400bb4e2 in BIO_ctrl () from /lib/libcrypto.so.2
#7  0x40040a0d in ssl3_accept () from /lib/libssl.so.2
#8  0x4004f82a in SSL_accept () from /lib/libssl.so.2
#9  0x4004b72d in ssl23_get_client_hello () from /lib/libssl.so.2
#10 0x4004b632 in ssl23_accept () from /lib/libssl.so.2
#11 0x4004f82a in SSL_accept () from /lib/libssl.so.2
#12 0x4031b56d in ssl_io_filter_connect (filter_ctx=0x8125e10)
    at ssl_engine_io.c:1053
#13 0x4031b957 in ssl_io_filter_input (f=0x81368d8, bb=0x8127ca8,
    mode=3909091333, block=134597532, readbytes=0) at ssl_engine_io.c:1220
#14 0x080724c1 in ap_get_brigade (next=0x805cb9c, bb=0xe9000005,
    mode=3909091333, block=3909091333, readbytes=-385875963)
    at util_filter.c:513
---Type <return> to continue, or q <return> to quit---
#15 0x080724c1 in ap_get_brigade (next=0x805cb9c, bb=0xe9000005,
    mode=3909091333, block=3909091333, readbytes=-385875963)
    at util_filter.c:513
#16 0x080735f8 in ap_rgetline_core (s=0x8137900, n=8192, read=0xbffff3ec,
    r=0x81378e8, fold=0, bb=0x8127ca8) at protocol.c:255
#17 0x08073c2e in read_request_line (r=0x81378e8, bb=0x8127ca8)
    at protocol.c:670
#18 0x0807429a in ap_read_request (conn=0x8137900) at protocol.c:932
#19 0x0805eba8 in ap_process_http_connection (c=0x8125a20) at http_core.c:285
#20 0x0806fee5 in ap_run_process_connection (c=0x8125a20) at connection.c:85
#21 0x08064e68 in child_main (child_num_arg=-385875963) at prefork.c:696
#22 0x08064fc4 in make_child (s=0xe9000005, slot=0) at prefork.c:790
#23 0x080650e6 in startup_children (number_to_start=1) at prefork.c:808
#24 0x0806590f in ap_mpm_run (_pconf=0x809d4b0, plog=0x80c7558, s=0x809f250)
    at prefork.c:1024
#25 0x0806ba7f in main (argc=3, argv=0xbffff644) at main.c:651
#26 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6

This apache has mod_dav_svn linked into it, but the page being requested
is the sites home page.

Best,
Blair

-- 
Blair Zajac <bl...@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: SSL core dump with httpd-2.0 HEAD

[Brian Pane <br...@cnet.com>]

On Sun, 2002-12-22 at 14:07, Blair Zajac wrote:
> I'm getting a core dump on apr/apr-util/httpd-2.0 from HEAD today
> with ssl

That looks like the known problem whereby code that
reuses a deleted brigade won't work with the brigade
allocation code.  I'm going to put the old allocation
code back into place this afternoon in prepatation for
the 2.0.44 release, which should make the problem go
away.

Brian