(this one has a long backtrace, so I'll save that for last.) I should mention that there were a bunch of seg faults within a minute or two, then nothing.
Here are the input buffers: (gdb) printf "%20s",((core_net_rec *)f.ctx).client_socket.head.data GET /docs/cygwin.html HTTP/1.1 Host: httpd.apache.org Accept: */* Referer: http://httpd.apache.org/docs/ User-Agent: NetAnts/1.25 Pragma: no-cache Cache-Control: no-cache Connection: close Range: bytes=20480- Notice the last two headers. We had a similar combination in the dumps from this weekend, except that they had Range: bytes=0- . NetAnts' web page says it is a download manager with several connections each downloading a small piece of the file. That may explain why the seg faults were clustered in time. (gdb) p r->status_line $3 = 0x8084280 "416 Requested Range Not Satisfiable" hmmm, that's what Jeff was getting yesterday with hand generated byterange requests using the Range: header we saw in the dumps, and we don't have an explanation for that yet. Since this one is asking for a non-zero starting value, it could be a legit 416. But when my browser request that page, I get Content Length: 20603, so this 416 looks bogus as well. core_output_filter is choking on an apr_bucket_read. Its brigade looks pretty complicated for an error page, but mod_include is filtering it, fwiw. (gdb) dump_brigade b dump of brigade 0x812c6a8 0: bucket=HEAP(0x81311e8), length=207, data=0x8131558 1: bucket=TRANSIENT(0x81315b0), length=5, data=0xbfbfe894 2: bucket=HEAP(0x81310e0), length=389, data=0x8131138 3: bucket=IMMORTAL(0x8131608), length=2, data=0x8083db9 4: bucket=IMMORTAL(0x8131660), length=5, data=0x8083dbc 5: bucket=EOS(0x8131298), length=0, data=0x0 6: bucket=(0x814fefc), length=135590000, data=0x280adea0 (gdb) p *bucket $4 = {link = {next = 0x812c6ac, prev = 0x8131298}, type = 0x8131010, length = 135590000, start = 2885363290195951352, data = 0x280adea0, free = 0x8159010, list = 0x8131190} (gdb) p *bucket.type $5 = {name = 0x8095900 "\001", num_func = 0, destroy = 0x8131000, read = 0, setaside = 0x58, split = 0x8131010, copy = 0x8131000} I'm going to play with byterange requests on my ThinkPad and see if strange stuff happens there too. I'm assuming there is no httpd test for "n-" byteranges? Greg ---------------------------------------------------------------------------------------- (gdb) bt #0 0x0 in ?? () #1 0x8078ab5 in core_output_filter (f=0x812c3d8, b=0x812c6a8) at core.c:3737 #2 0x8070cb1 in ap_pass_brigade (next=0x812c3d8, bb=0x8156fb8) at util_filter.c:534 #3 0x805e937 in chunk_filter (f=0x8150088, b=0x8156fb8) at http_core.c:260 #4 0x8070cb1 in ap_pass_brigade (next=0x8150088, bb=0x8156fb8) at util_filter.c:534 #5 0x8060d5e in ap_http_header_filter (f=0x8159808, b=0x8156fb8) at http_protocol.c:1474 #6 0x8070cb1 in ap_pass_brigade (next=0x8159808, bb=0x8156fb8) at util_filter.c:534 #7 0x8073152 in ap_content_length_filter (f=0x81597f0, b=0x8156fb8) at protocol.c:1232 #8 0x8070cb1 in ap_pass_brigade (next=0x81597f0, bb=0x8156fb8) at util_filter.c:534 #9 0x281e3bbb in handle_include (ctx=0x812c600, bb=0xbfbfeef4, r=0x8159048, f=0x8156468, head_ptr=0x81310e0, inserted_head=0xbfbfeaa0) at mod_include.c:1250 #10 0x281e69c1 in send_parsed_content (bb=0xbfbfeef4, r=0x8159048, f=0x8156468) at mod_include.c:3109 #11 0x281e7256 in includes_filter (f=0x8156468, b=0x8156fb8) at mod_include.c:3387 #12 0x8070cb1 in ap_pass_brigade (next=0x8156468, bb=0x8156fb8) at util_filter.c:534 #13 0x8073433 in ap_old_write_filter (f=0x8156fa0, bb=0x814f060) at protocol.c:1333 #14 0x8070cb1 in ap_pass_brigade (next=0x8156fa0, bb=0x814f060) at util_filter.c:534 #15 0x8072b17 in end_output_stream (r=0x8159048) at protocol.c:995 #16 0x8072b7b in ap_finalize_request_protocol (r=0x8159048) at protocol.c:1016 #17 0x80620e0 in ap_send_error_response (r=0x8159048, recursive_error=0) #18 0x806332f in ap_die (type=416, r=0x8159048) at http_request.c:205 #19 0x8060d0d in ap_http_header_filter (f=0x8159808, b=0x8156f48) at http_protocol.c:1325 #20 0x8070cb1 in ap_pass_brigade (next=0x8159808, bb=0x8156f48) at util_filter.c:534 #21 0x807327b in ap_content_length_filter (f=0x81597f0, b=0x8156f48) at protocol.c:1264 #22 0x8070cb1 in ap_pass_brigade (next=0x81597f0, bb=0x8156f48) at util_filter.c:534 #23 0x8062e45 in ap_byterange_filter (f=0x81597d8, bb=0x8156558) at http_protocol.c:2760 #24 0x8070cb1 in ap_pass_brigade (next=0x81597d8, bb=0x8156558) at util_filter.c:534 #25 0x281e3bbb in handle_include (ctx=0x812c600, bb=0xbfbff734, r=0x8159048, f=0x8156468, head_ptr=0x8131088, inserted_head=0xbfbff2e0) at mod_include.c:1250 #26 0x281e69c1 in send_parsed_content (bb=0xbfbff734, r=0x8159048, f=0x8156468) at mod_include.c:3109 #27 0x281e7256 in includes_filter (f=0x8156468, b=0x8156558) at mod_include.c:3387 #28 0x8070cb1 in ap_pass_brigade (next=0x8156468, bb=0x8156558) at util_filter.c:534 #29 0x8077fa2 in default_handler (r=0x8159048) at core.c:3247 #30 0x8065eef in ap_run_handler (r=0x8159048) at config.c:193 #31 0x806648f in ap_invoke_handler (r=0x8159048) at config.c:373 #32 0x8063413 in ap_process_request (r=0x8159048) at http_request.c:261 #33 0x805e9db in ap_process_http_connection (c=0x812c120) at http_core.c:291 #34 0x806ecf3 in ap_run_process_connection (c=0x812c120) at connection.c:85 #35 0x806f008 in ap_process_connection (c=0x812c120, csd=0x812c048) at connection.c:207 #36 0x80648f0 in child_main (child_num_arg=165) at prefork.c:671 #37 0x8064a5a in make_child (s=0x809dd60, slot=165) at prefork.c:765 #38 0x8064c45 in perform_idle_server_maintenance (p=0x809c010) at prefork.c:900 #39 0x8065022 in ap_mpm_run (_pconf=0x809c010, plog=0x80c6010, s=0x809dd60) at prefork.c:1092 #40 0x806a8dd in main (argc=1, argv=0xbfbffb5c) at main.c:622 #41 0x805e5c5 in _start ()
