Greg Ames wrote:
>
> Ryan Bloom wrote:
> >
> > I have bumped the tag on mod_include and mod_ssl, and I have re-rolled
> > the tarballs. The new version of Apache 2.0.24 can be found at
> > http://dev.apache.org/dist
>
> daedalus says, "+1".
daedalus changed its mind. We took two seg faults in mod_include within
2 hours, on the same URL
http://httpd.apache.org/docs/new_features_1_3.html , so I moved us back
to 2.0.22. The dumps are /usr/local/apache2_0_24/corefiles/httpd.core.1
and .2 .
The backtraces look identical. find_start_sequence() has a very strange
looking bucket:
(gdb) p *dptr
$2 = {link = {next = 0x80b63a0, prev = 0x80b63a0}, type = 0x0,
length = 136387676, start = 578597859445151664, data = 0x8211c2c,
free = 0x821100c}
We are recursively invoking handle_include, which it seems designed to
do. But I see the filename and URI changing in the request rec's from
new_features_1_3.html to .html.html to .html.en, which seems like
something I would expect negotiation to straighten out, not SSI. It
also looks like send_parsed_content is using the original request rec
each time it's invoked. Maybe that's OK, it just seems odd.
Greg
(gdb) bt
#0 0x281c282d in find_start_sequence (dptr=0x8211c60, ctx=0x81e800c,
bb=0x8211c3c, do_cleanup=0xbfbf8cd8) at mod_include.c:162
#1 0x281c5e7f in send_parsed_content (bb=0xbfbf9138, r=0x821703c,
f=0x82000ac)
at mod_include.c:2353
#2 0x281c697f in includes_filter (f=0x82000ac, b=0x8211c3c)
at mod_include.c:2760
#3 0x806a5e9 in ap_pass_brigade (next=0x82000ac, bb=0x8211b7c)
at util_filter.c:242
#4 0x8071aff in ap_sub_req_output_filter (f=0x821138c, bb=0x8211b7c)
at request.c:1265
#5 0x806a5e9 in ap_pass_brigade (next=0x821138c, bb=0x8211b7c)
at util_filter.c:242
#6 0x806ffa4 in default_handler (r=0x821103c) at core.c:3033
#7 0x80621bc in ap_run_handler (r=0x821103c) at config.c:185
#8 0x8062637 in ap_invoke_handler (r=0x821103c) at config.c:344
#9 0x8072301 in ap_run_sub_req (r=0x821103c) at request.c:1608
#10 0x281c3612 in handle_include (ctx=0x81f900c, bb=0xbfbfd778,
r=0x821703c,
f=0x8200094, head_ptr=0x80b61c0, inserted_head=0xbfbfd310)
at mod_include.c:857
#11 0x281c62e9 in send_parsed_content (bb=0xbfbfd778, r=0x821703c,
f=0x8200094)
at mod_include.c:2500
#12 0x281c697f in includes_filter (f=0x8200094, b=0x82006a4)
at mod_include.c:2760
#13 0x806a5e9 in ap_pass_brigade (next=0x8200094, bb=0x8200244)
at util_filter.c:242
#14 0x806ffa4 in default_handler (r=0x821703c) at core.c:3033
#15 0x80621bc in ap_run_handler (r=0x821703c) at config.c:185
#16 0x8062637 in ap_invoke_handler (r=0x821703c) at config.c:344
#17 0x805fe8c in process_request_internal (r=0x821703c) at
http_request.c:378
#18 0x805ff6a in ap_process_request (r=0x821703c) at http_request.c:444
#19 0x805c02a in ap_process_http_connection (c=0x814710c) at
http_core.c:287
#20 0x80691a8 in ap_run_process_connection (c=0x814710c) at
connection.c:82
#21 0x806932c in ap_process_connection (c=0x814710c) at connection.c:219
#22 0x80610be in child_main (child_num_arg=108) at prefork.c:829
#23 0x8061206 in make_child (s=0x80bd554, slot=108) at prefork.c:916
#24 0x80613dd in perform_idle_server_maintenance (p=0x80bd00c)
at prefork.c:1057
#25 0x8061736 in ap_mpm_run (_pconf=0x80bd00c, plog=0x80ed00c,
s=0x80bd554)
at prefork.c:1234
#26 0x8065d38 in main (argc=1, argv=0xbfbffb60) at main.c:427
#27 0x805bc5d in _start ()
