httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Plüm, Rüdiger, VF-Group" <ruediger.pl...@vodafone.com>
Subject Re: segfaults / core dumps caused by ap_internal_fast_redirect
Date Tue, 07 Apr 2009 15:12:30 GMT
 

> -----Ursprüngliche Nachricht-----
> Von: Joe Orton 
> Gesendet: Dienstag, 7. April 2009 15:51
> An: dev@httpd.apache.org
> Betreff: Re: segfaults / core dumps caused by 
> ap_internal_fast_redirect
> 
> On Tue, Apr 07, 2009 at 01:29:20PM +0200, "Plüm, Rüdiger, 
> VF-Group" wrote:
> ...
> > I think the reason for this behaviour is the following:
> > 
> > 1. The subrequest created by mod_dir uses a subpool of 
> r->pool for its allocations.
> > 2. ap_internal_fast_redirect uses the data allocated out of 
> this subpool for r (especially uri / filename / per_dir_config)
> > 3. The call to apr_pool_destroy in frame 9 destroys the 
> request pool of r.
> > 4. ap_ident_lookup in frame 2 is called by a cleanup of 
> r->pool and uses data in r (r->per_dir_config in this case),
> >    but the subpools of r->pool are already destroyed as the 
> cleanups run after the destruction of the subpools.
> >    ==> BOOM.
> > 
> > The code has been this way for a long time. Why didn't we 
> see this earlier?
> 
> Doing the logging in a pool cleanup is a crazy new feature 
> with the EOR 
> bucket in httpd trunk.  I remember going through a bunch of similar 

Sure this is crazy, but OTOH the request_rec data should be valid at this
point of time. So IMHO it is not the fault of the EOR bucket construction that
we run into trouble here but the bad thing is that ap_internal_fast_redirect
is inserting shorter living data (albeit it dies only short before our cleanup,
but dead is dead) into the request_rec.

> backtraces when it was committed.  I vaguely recall seeing 
> similar ones 
> more recently with trunk pool-debug/efence builds.
> 
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200510.mbox
> /<20051028081011.GA10086@redhat.com>
> 

Thanks for the pointer. Do you still have the upper part of the stack trace
at hand?

Regards

Rüdiger

Mime
View raw message