httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <>
Subject Core dump in mod-include
Date Fri, 14 Dec 2001 17:32:11 GMT
hi guys.
we've been investigating a couple of core dumps in some testing and we 
think we found one in mod-include.

here is the email thread.
does anyone have any reason NOT to reset the state when reseting
the bytes parsed ?

It seems to fix this problem, but I'm fearful that it will cause 
something else to break...

 > >  - apparently, the brigade only has an EOS, it is not splittable.
 > >    But here mod_include is trying to do so, hence messed up
 > > the brigade and
 > >    the later usage of *bb caused core.
 > >    Every time I saw, when mod_include reach that line, it cores soon.
 > >
 > >  - Question is, why a brigade that only has EOS bucket can reach here?
 > >    If it supposed to be that way, how to split such a brigade
 > > properly?
 > I think it is valid for the brigade to have only EOS in that situation.
 > The brigade has several buckets before the EOS when it enters the
 > send_parsed_content function, but the buckets before the EOS may have
 > been sent on to the next filter by the time it gets to the end.
 > The strange thing, though, is that if you reach line 2981,it means that
 > there was a partial SSI directive at the end of the content.  And indeed
 > the ctx->head_start_bucket appears to have an SSI directive at the start
 > of its data.  But two things are wrong: that bucket isn't on the
 > brigade,
 > and it looks like a complete (not partial) SSI directive.

Yeah, the PARSE_DIRECTIVE state shoule not reach that line for EOS.
Because the EOS is from ap_finalize_request_protocol(), it seems to
be the only bucket. So I checked the includes_filter().
It tried to reuse the filter's previous ctx in the begining,
but it only cleaned bytes_parsed.
     if (!f->ctx) {
	...create new ctx here...
     else {
         ctx->bytes_parsed = 0;

I added a line after the ctx->bytes_parsed = 0 to reset the state:
     else {
         ctx->bytes_parsed = 0;
/**/    ctx->state = PRE_HEAD;

It is running for over half hour now (with all SSI turned back on and
with dw, ad module turned back on), no more core dump for port 8001 !
(Port 80 still has some though, I am contacting Justin Wang to see
if I can do some tests there too.)

So the ctx->state not cleaned when reuse, is it on purpose?
Is this a good fix? (The problem still could be caused by something
before this...)

-- Jin

View raw message