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. http://mail-archives.apache.org/mod_mbox/httpd-dev/200510.mbox/<[email protected]>
