httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: segfaults / core dumps caused by ap_internal_fast_redirect
Date Tue, 07 Apr 2009 13:51:15 GMT
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 
backtraces when it was committed.  I vaguely recall seeing similar ones 
more recently with trunk pool-debug/efence builds.<>

View raw message