Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Sender: gregames@Mail.MeepZor.Com
Message-ID: <3B8080FC.916750BD@remulak.net>
Date: Sun, 19 Aug 2001 23:16:12 -0400
From: Greg Ames <gregames@remulak.net>
MIME-Version: 1.0
To: new-httpd@apache.org
Subject: Re: New tarballs are up.
References: <01081722392004.22472@koj.rkbloom.net>
 <3B7FDA15.F9F813CC@remulak.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: O

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 ()