SSL segfault on HEAD

[Scott Lamb]

HEAD (as of sometime yesterday) is segfaulting on me. Stack trace below. This happens on all SSL requests; others seem fine. This on Linux with RedHat's openssl-0.9.6b-28.

I'm wondering if this has anything to do with the ssl changes on the 14th. They touched ssl_engine_io.c, though there's no immediate culprit to my (uneducated) eye.

The particular revs I've got:

ssl_engine_io.c 1.102
apr_buckets_simple.c 1.41
apr_buckets_alloc.c 1.8

Here's the backtrace:

(gdb) run -DMAIN -X
Starting program: /usr/local/apache2/bin/httpd -DMAIN -X
[New Thread 1024 (LWP 26273)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 26273)]
apr_bucket_alloc (size=32, list=0x805ccec) at apr_buckets_alloc.c:127
127 list->freelist = node->next;
(gdb) print *node
Cannot access memory at address 0xe9000005
#0 apr_bucket_alloc (size=32, list=0x805ccec) at apr_buckets_alloc.c:127
#1 0x40111bfa in apr_bucket_transient_create (buf=0x8141750 "\024\003\001",
length=43, list=0x805ccec) at apr_buckets_simple.c:151
#2 0x4045683a in bio_filter_out_flush (bio=0x81308d8) at ssl_engine_io.c:174
#3 0x40456c65 in bio_filter_out_ctrl (bio=0x81308d8, cmd=11, num=0, ptr=0x0)
at ssl_engine_io.c:297
#4 0x4009bfa6 in BIO_ctrl () from /lib/libcrypto.so.2
#5 0x4009fc6a in buffer_ctrl () from /lib/libcrypto.so.2
#6 0x4009bfa6 in BIO_ctrl () from /lib/libcrypto.so.2
#7 0x400284bc in ssl3_accept () from /lib/libssl.so.2
#8 0x400353c0 in SSL_accept () from /lib/libssl.so.2
#9 0x40032078 in ssl23_get_client_hello () from /lib/libssl.so.2
#10 0x40031865 in ssl23_accept () from /lib/libssl.so.2
#11 0x400353c0 in SSL_accept () from /lib/libssl.so.2
#12 0x40457829 in ssl_io_filter_connect (filter_ctx=0x8133548)
at ssl_engine_io.c:1057
#13 0x40457d8c in ssl_io_filter_input (f=0x8146778, bb=0x813f848,
mode=AP_MODE_GETLINE, block=APR_BLOCK_READ, readbytes=0)
at ssl_engine_io.c:1307
#14 0x0806ec12 in ap_get_brigade (next=0x8146778, bb=0x813f848,
mode=AP_MODE_GETLINE, block=APR_BLOCK_READ, readbytes=0)
at util_filter.c:514
#15 0x0806ec12 in ap_get_brigade (next=0x81483a8, bb=0x813f848,
mode=AP_MODE_GETLINE, block=APR_BLOCK_READ, readbytes=0)
at util_filter.c:514
#16 0x0806fa0c in ap_rgetline_core (s=0x81477a0, n=8192, read=0xbffff6cc,
r=0x8147788, fold=0, bb=0x813f848) at protocol.c:255
#17 0x0806ff75 in read_request_line (r=0x8147788, bb=0x813f848)
at protocol.c:670
#18 0x080704f7 in ap_read_request (conn=0x8133160) at protocol.c:929
#19 0x0805ecdb in ap_process_http_connection (c=0x8133160) at http_core.c:312
#20 0x0806ce12 in ap_run_process_connection (c=0x8133160) at connection.c:85
#21 0x08063f7d in child_main (child_num_arg=0) at prefork.c:696
#22 0x08064030 in make_child (s=0x8098910, slot=0) at prefork.c:736
#23 0x0806411a in startup_children (number_to_start=5) at prefork.c:808
#24 0x0806441c in ap_mpm_run (_pconf=0x8096b70, plog=0x80c0c18, s=0x8098910)
at prefork.c:1024
#25 0x08069607 in main (argc=3, argv=0xbffff934) at main.c:651
#26 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

Thanks,
Scott