Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: segfaults / core dumps caused by ap_internal_fast_redirect
Date: Tue, 7 Apr 2009 17:12:30 +0200
Message-ID: 
 <99EA83DCDE961346AFA9B5EC33FEC08B02036224@VF-MBX11.internal.vodafone.com>
In-Reply-To: <20090407135115.GA10099@redhat.com>
Thread-Topic: Re: segfaults / core dumps caused by ap_internal_fast_redirect
Thread-Index: Acm3iASGLt6AVeAtTk6k2fykWPIAcQACnN9Q
References: 
 <99EA83DCDE961346AFA9B5EC33FEC08B01FAE5B6@VF-MBX11.internal.vodafone.com>
 <20090407135115.GA10099@redhat.com>
From: =?iso-8859-1?Q?=22Pl=FCm=2C_R=FCdiger=2C_VF-Group=22?=
 <ruediger.pluem@vodafone.com>
To: <dev@httpd.apache.org>

=20

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

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=20
> similar ones=20
> more recently with trunk pool-debug/efence builds.
>=20
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200510.mbox
> /<20051028081011.GA10086@redhat.com>
>=20

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

Regards

R=FCdiger