duh! meant to post this to dev@httpd, but just sent it to Brian
Brian Pane wrote:
Greg Ames wrote:
With a cvs checkout from Wednesday PM on daedalus, I get seg faults in
ap_save_brigade() called by send_parsed_content() in mod_include.c .
Do the values of ctx-head_start_bucket and ctx-head_start_index look
reasonable when it does the bucket_split and brigade_split just before
the segv? If those were bad, it might explain the trashed brigade.
(I can't recreate the crash on Linux either; it never even enters that
branch of the code.)
The problem is triggered by a dropped network connection. This causes
one of the include virtual subrequests to fail with EPIPE. It unwinds
back to ap_run_sub_req, which remembers the bad return value and then
calls ap_finalize_sub_req_protocol, which calls end_output_stream. This
builds a brigade containing an EOS bucket only, which is passed down the
filter chain. The first filter is ap_sub_req_output_filter, which
strips the EOS bucket creating an empty brigade, which is passed down.
includes_filter is next. It calls send_parsed_content, where ctx-state
== PARSE_DIRECTIVE and ctx-head_start_bucket points is non-null. (We
never unwound all the way back to the main request's instance of
send_parsed_content/handle_include where some cleanup would happen.)
The second instance of send_parsed content quickly bails out of its main
while loop because the brigade is empty, but code after the loop (line
2959 in the current HEAD) tries to split the empty brigade at
ctx-head_start_bucket, which create two bad brigades and leads to the
seg fault.
I can patch send_parsed_content so that we bypass the failing section of
code when it sees an empty brigade. But I'm wondering if that is too
localized. ap_finalize_sub_req_protocol / end_output_stream /
ap_sub_req_output_filter are passing down an empty brigade. What's the
point, especially when the connection is gone? ap_run_sub_req did get
an EPIPE.
Greg
---
more of the backtrace...should have posted more originally
#0 0x806dce3 in ap_save_brigade (f=0x8248c9c, saveto=0x8265054,
b=0xbfbfad44,
p=0x824800c) at util_filter.c:296
#1 0x281e3abd in send_parsed_content (bb=0xbfbfb1b8, r=0x824803c,
f=0x8248c9c)
at mod_include.c:2960
#2 0x281e3e54 in includes_filter (f=0x8248c9c, b=0x8248e4c)
at mod_include.c:3094
#3 0x806dc8d in ap_pass_brigade (next=0x8248c9c, bb=0x8248e4c)
at util_filter.c:276
#4 0x80769cf in ap_sub_req_output_filter (f=0x82483a4, bb=0x8248e4c)
at request.c:1392
#5 0x806dc8d in ap_pass_brigade (next=0x82483a4, bb=0x8248e4c)
at util_filter.c:276
#6 0x806f63c in end_output_stream (r=0x824803c) at protocol.c:729
#7 0x806f662 in ap_finalize_sub_req_protocol (sub=0x824803c) at
protocol.c:734
#8 0x8076e04 in ap_run_sub_req (r=0x824803c) at request.c:1740
#9 0x281e09e3 in handle_include (ctx=0x81c100c, bb=0xbfbfd7e8,
r=0x812803c,
f=0x81352d4, head_ptr=0x80e8400, inserted_head=0xbfbfd380)
at mod_include.c:1113
#10 0x281e3749 in send_parsed_content (bb=0xbfbfd7e8, r=0x812803c,
f=0x81352d4)
at mod_include.c:2844
#11 0x281e3e54 in includes_filter (f=0x81352d4, b=0x823f904)
at mod_include.c:3094
#12 0x806dc8d in ap_pass_brigade (next=0x81352d4, bb=0x813543c)
at util_filter.c:276
#13 0x80744da in default_handler (r=0x812803c) at core.c:2753
#14 0x8063d93 in ap_run_handler (r=0x812803c) at config.c:185
#15 0x806431f in ap_invoke_handler (r=0x812803c) at config.c:344
#16 0x8061411 in ap_process_request (r=0x812803c) at http_request.c:286
#17 0x805cd26 in ap_process_http_connection (c=0x8122114) at
http_core.c:287
#18 0x806c2d7 in ap_run_process_connection (c=0x8122114) at
connection.c:82
#19 0x806c495 in ap_process_connection (c=0x8122114) at connection.c:219
#20 0x806298c in child_main (child_num_arg=41) at prefork.c:830
#21 0x8062ae2 in make_child (s=0x8095804, slot=41) at prefork.c:917
#22 0x8062d35 in perform_idle_server_maintenance (p=0x809500c)
at prefork.c:1058
#23 0x80630f6 in ap_mpm_run (_pconf=0x809500c, plog=0x80cb00c,
s=0x8095804)
at prefork.c:1236
#24 0x806833f in main (argc=3, argv=0xbfbffbd0) at main.c:431
#25 0x805c8dd in _start ()
