You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@covalent.net> on 2001/08/18 07:39:20 UTC
New tarballs are up.
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
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: New tarballs are up.
Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:
> I expect we'll take a seg fault before I'm ready to hit the sack
> tonight.
got one, but it died in core_output_filter this time, with another wacky
looking bucket. mod_include is involved, but there's no recursion this
time, and some strange headers came in from the client.
Greg
Dump name: /usr/local/apache2_0_24/corefiles/httpd.core.3
filename: /www/httpd.apache.org/docs/misc/FAQ.html
status line: "416 Requested Range Not Satisfiable"
r->headers_in:
'0] 'Accept'='Accept: */*
[1] 'Connection'='Keep-Alive'
[2] 'Host'='httpd.apache.org'
[3] 'If-Range'='"ded66-156c-4e1dcc80"'
[4] 'Range'='bytes=23286-'
[5] 'Unless-Modified-Since'='Sat, 03 Mar 2001 05:07:46 GMT'
#0 0x8070128 in core_output_filter (f=0x8147384, b=0x82140bc) at
core.c:3136
3136 rv = apr_bucket_read(e, &str, &n,
APR_BLOCK_READ);
(gdb) p *e
$4 = {link = {next = 0x82140c0, prev = 0x80b61c0}, type = 0x2d617472,
length = 136231516, start = 578597859445151664, data = 0x81eb924,
free = 0x820200c}
(gdb) p *b
$5 = {p = 0x814700c, list = {next = 0x80b6160, prev = 0x81eba60}}
(gdb) bt
#0 0x8070128 in core_output_filter (f=0x8147384, b=0x82140bc) at
core.c:3136
#1 0x806a5e9 in ap_pass_brigade (next=0x8147384, bb=0x81eb41c)
at util_filter.c:242
#2 0x805db87 in ap_http_header_filter (f=0x81eb32c, b=0x81eb41c)
at http_protocol.c:1331
#3 0x806a5e9 in ap_pass_brigade (next=0x81eb32c, bb=0x81eb41c)
at util_filter.c:242
#4 0x806c127 in ap_content_length_filter (f=0x81eb314, b=0x81eb41c)
at protocol.c:957
#5 0x806a5e9 in ap_pass_brigade (next=0x81eb314, bb=0x81eb41c)
at util_filter.c:242
#6 0x281c3869 in handle_include (ctx=0x821000c, bb=0xbfbfd778,
r=0x820203c,
f=0x81eb2e4, head_ptr=0x80b6240, inserted_head=0xbfbfcb10)
at mod_include.c:905
#7 0x281c6579 in send_parsed_content (bb=0xbfbfd778, r=0x820203c,
f=0x81eb2e4)
at mod_include.c:2556
#8 0x281c6c56 in includes_filter (f=0x81eb2e4, b=0x81eb41c)
at mod_include.c:2822
#9 0x806a5e9 in ap_pass_brigade (next=0x81eb2e4, bb=0x81eb41c)
at util_filter.c:242
#10 0x806ffa4 in default_handler (r=0x820203c) at core.c:3033
#11 0x80621bc in ap_run_handler (r=0x820203c) at config.c:185
#12 0x8062637 in ap_invoke_handler (r=0x820203c) at config.c:344
#13 0x805fe8c in process_request_internal (r=0x820203c) at
http_request.c:378
#14 0x805ff6a in ap_process_request (r=0x820203c) at http_request.c:444
#15 0x805c02a in ap_process_http_connection (c=0x814710c) at
http_core.c:287
#16 0x80691a8 in ap_run_process_connection (c=0x814710c) at
connection.c:82
#17 0x806932c in ap_process_connection (c=0x814710c) at connection.c:219
#18 0x80610be in child_main (child_num_arg=200) at prefork.c:829
#19 0x8061206 in make_child (s=0x80bd554, slot=200) at prefork.c:916
#20 0x80613dd in perform_idle_server_maintenance (p=0x80bd00c)
at prefork.c:1057
#21 0x8061736 in ap_mpm_run (_pconf=0x80bd00c, plog=0x80ed00c,
s=0x80bd554)
at prefork.c:1234
#22 0x8065d38 in main (argc=1, argv=0xbfbffb60) at main.c:427
#23 0x805bc5d in _start ()
Re: New tarballs are up.
Posted by Greg Ames <gr...@remulak.net>.
Greg Ames wrote:
> We haven't been able to recreate the seg faults so far on daedalus on
> port 8092, or on other boxes. The plan to debug these is to add
> diagnostic code to mod_include that creates a picture of the bucket
> brigade within the stack (automatic string variables) at various key
> points, then put 2.0.24 back into production with the instrumented
> (debug) version of mod_include.
OK, we're back on 2.0.24 as of Monday, 20-Aug-2001 17:30:57 PDT , with
the instrumented version of mod_include this time. Thanks to Jeff for
providing the diagnostic code in short order.
I expect we'll take a seg fault before I'm ready to hit the sack
tonight. If we do, this dump should be easier to debug. (look at
variable "bbstr" in all the key functions in mod_include.) If not,
fine, I'll leave it running.
Greg
Re: New tarballs are up.
Posted by Cliff Woolley <cl...@yahoo.com>.
On Mon, 20 Aug 2001, Greg Ames wrote:
> We haven't been able to recreate the seg faults so far on daedalus on
> port 8092, or on other boxes. The plan to debug these is to add
> diagnostic code to mod_include that creates a picture of the bucket
> brigade within the stack (automatic string variables) at various key
> points, then put 2.0.24 back into production with the instrumented
> (debug) version of mod_include.
>
> Then, if the trigger conditions are frequent, we should get a dump soon
> that will be easier to debug, and we can fix, re-tag, and re-roll. If
> the trigger conditions are infrequent and we don't get more seg faults,
> then we might as well bless 2.0.24.
>
> Opinions?
+1.
PS: I'll take another look later, but that bucket dump you posted earlier
kinda looked like what the sentinel would look like if you deref'ed it as
an apr_bucket... if you see one of those again, test it to see if it's the
sentinel.
--Cliff
--------------------------------------------------------------
Cliff Woolley
cliffwoolley@yahoo.com
Charlottesville, VA
Re: New tarballs are up.
Posted by Greg Ames <gr...@remulak.net>.
Justin Erenkrantz wrote:
>
> On Sun, Aug 19, 2001 at 11:16:12PM -0400, Greg Ames wrote:
> > 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
>
> Has daedalus changed its vote to -1? Is 2.0.24 dead now? -- justin
An excellent question. I don't know how frequent the seg faults would
have been had I left it running in production. Getting two seg faults
in less than 2 hours is far less reliable than 2.0.22 has been on
daedalus. Is it acceptable? That's the tough question, when we have no
clue what triggers the bug.
We haven't been able to recreate the seg faults so far on daedalus on
port 8092, or on other boxes. The plan to debug these is to add
diagnostic code to mod_include that creates a picture of the bucket
brigade within the stack (automatic string variables) at various key
points, then put 2.0.24 back into production with the instrumented
(debug) version of mod_include.
Then, if the trigger conditions are frequent, we should get a dump soon
that will be easier to debug, and we can fix, re-tag, and re-roll. If
the trigger conditions are infrequent and we don't get more seg faults,
then we might as well bless 2.0.24.
Opinions?
Greg
Re: New tarballs are up.
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Sun, Aug 19, 2001 at 11:16:12PM -0400, Greg Ames wrote:
> 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
Has daedalus changed its vote to -1? Is 2.0.24 dead now? -- justin
Re: New tarballs are up.
Posted by Greg Ames <gr...@remulak.net>.
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 ()
Re: New tarballs are up.
Posted by Greg Ames <gr...@remulak.net>.
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".
The problem with http://httpd.apache.org/docs-2.0/misc/FAQ.html is
gone. Log replay looks good, beating on that URL doesn't produce
failures any more. Jeff's last fix to mod_include must have taken care
of it.
Anyway, I bounced apache.org's production web server over to 2.0.24 on
Sunday, 19-Aug-2001 08:03:26 PDT.
Greg