I'm going to bounce the server on daedalus back to 2.0.29 later tonight. We
need fixes for the input side problems and we need a working bug db.
This one could have the same underlying cause as the other dumps, but it's hard
to say at this point. Maybe gdb is confused by recursive ap_rgetline calls?
to get to this one on daedalus,
cd /usr/local/apache2.0.31.patched/
gdb bin/httpd corefiles/httpd.core.3
#0 0x2 in ?? ()
#1 0x8070cb3 in get_mime_headers (r=0x8131048) at protocol.c:687
#2 0x8070f9b in ap_read_request (conn=0x8124120) at protocol.c:801
#3 0x805ddb1 in ap_process_http_connection (c=0x8124120) at http_core.c:300
#4 0x806d643 in ap_run_process_connection (c=0x8124120) at connection.c:84
#5 0x806d958 in ap_process_connection (c=0x8124120, csd=0x8124048)
at connection.c:231
#6 0x8063854 in child_main (child_num_arg=445) at prefork.c:722
#7 0x80639ae in make_child (s=0x809a8d8, slot=445) at prefork.c:812
#8 0x8063bdd in perform_idle_server_maintenance (p=0x8099010) at prefork.c:953
#9 0x8063f56 in ap_mpm_run (_pconf=0x8099010, plog=0x80bf010, s=0x809a8d8)
at prefork.c:1126
#10 0x8069676 in main (argc=1, argv=0xbfbffb18) at main.c:498
#11 0x805d965 in _start ()
(gdb) fr 1
#1 0x8070cb3 in get_mime_headers (r=0x8131048) at protocol.c:687
687 rv = ap_rgetline(&field, DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2,
(gdb) list
682 */
683 while(1) {
684 apr_status_t rv;
685
686 field = NULL;
687 rv = ap_rgetline(&field, DEFAULT_LIMIT_REQUEST_FIELDSIZE + 2,
688 &len, r, 1);
689
690 /* ap_rgetline returns APR_ENOSPC if it fills up the buffer
before
691 * finding the end-of-line. This is only going to happen if it
