Jeff Trawick <[EMAIL PROTECTED]> writes:
> Jeff Trawick <[EMAIL PROTECTED]> writes:
>
> > okay, do try it, but (unlike somebody last night) don't try it on daedalus
> >
> > GET / HTTP/1.1
> > Accept: */*
> > Host: test
> > Content-Type: application/x-www-form-urlencoded
> > Transfer-Encoding: chunked
> >
> > AAAAAAAAAAAAAAAAAAA
>
> Is this test (with cr-lf added where appropriate) working consistently
> for everybody that tries?
>
> Yesterday afternoon:
>
> on one build I was getting a 200 followed by a 500 (access_log said
> 500 was for method AAAAAAAAA...)
>
> on another build I was getting a segfault
Running HEAD, we get a segfault when the bogus request is for a
resource for which we aren't authorized. Here is the traceback:
#0 0x4014bd41 in __kill () from /lib/libc.so.6
#1 0x4014b9b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2 0x4014d0d8 in abort () at ../sysdeps/generic/abort.c:88
#3 0x80be80c in ap_log_assert (szExp=0x80e945b "readbytes > 0",
szFile=0x80e93e4 "http_protocol.c", nLine=957) at log.c:689
#4 0x807dc8c in ap_http_filter (f=0x81b46a8, b=0x81b3f48,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=-1)
at http_protocol.c:957
#5 0x80cae79 in ap_get_brigade (next=0x81b46a8, bb=0x81b3f48,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at util_filter.c:507
#6 0x80d5125 in net_time_filter (f=0x81b3f68, b=0x81b3f48,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at core.c:3324
#7 0x80cae79 in ap_get_brigade (next=0x81b3f68, bb=0x81b3f48,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at util_filter.c:507
#8 0x807f46d in ap_get_client_block (r=0x81b3808,
buffer=0xbfffb5c0, bufsiz=8192)
at http_protocol.c:1769
#9 0x807f765 in ap_discard_request_body (r=0x81b3808) at http_protocol.c:1874
#10 0x8081df9 in ap_die (type=401, r=0x81b3808) at http_request.c:153
#11 0x807eaf8 in ap_http_header_filter (f=0x81b3fb0, b=0x81b4b48)
at http_protocol.c:1448
#12 0x80caefd in ap_pass_brigade (next=0x81b3fb0, bb=0x81b4b48)
at util_filter.c:534
#13 0x80ce3aa in ap_content_length_filter (f=0x81b3f98, b=0x81b4b48)
at protocol.c:1292
#14 0x80caefd in ap_pass_brigade (next=0x81b3f98, bb=0x81b4b48)
at util_filter.c:534
#15 0x8081223 in ap_byterange_filter (f=0x81b3f80, bb=0x81b4b48)
at http_protocol.c:2745
#16 0x80caefd in ap_pass_brigade (next=0x81b3f80, bb=0x81b4b48)
at util_filter.c:534
#17 0x807d94c in ap_http_filter (f=0x81b46a8, b=0x81b3f48,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at http_protocol.c:888
#18 0x80cae79 in ap_get_brigade (next=0x81b46a8, bb=0x81b3f48,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at util_filter.c:507
#19 0x80d5125 in net_time_filter (f=0x81b3f68, b=0x81b3f48,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at core.c:3324
#20 0x80cae79 in ap_get_brigade (next=0x81b3f68, bb=0x81b3f48,
mode=AP_MODE_READBYTES, block=APR_BLOCK_READ, readbytes=8192)
at util_filter.c:507
#21 0x807f46d in ap_get_client_block (r=0x81b3808,
buffer=0xbfffd878, bufsiz=8192) at http_protocol.c:1769
#22 0x807f765 in ap_discard_request_body (r=0x81b3808) at http_protocol.c:1874
#23 0x8081df9 in ap_die (type=401, r=0x81b3808) at http_request.c:153
#24 0x80820c2 in ap_process_request (r=0x81b3808) at http_request.c:277
#25 0x807bbe1 in ap_process_http_connection (c=0x81ad848) at http_core.c:291
#26 0x80c7ce0 in ap_run_process_connection (c=0x81ad848) at connection.c:85
#27 0x80c8145 in ap_process_connection (c=0x81ad848, csd=0x81ad788)
at connection.c:207
#28 0x80b80a4 in child_main (child_num_arg=4) at prefork.c:671
#29 0x80b8259 in make_child (s=0x8158c50, slot=4) at prefork.c:765
#30 0x80b82f2 in startup_children (number_to_start=1) at prefork.c:783
#31 0x80b87f1 in ap_mpm_run (_pconf=0x810cfe8, plog=0x814d0e8, s=0x8158c50)
at prefork.c:999
#32 0x80bfe7c in main (argc=3, argv=0xbffffa84) at main.c:646
(gdb)
cute recursion, huh?
I'll try to see what is up with the weird 200-followed-by-500
problem.
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
