Greg Stein wrote on Thu, Apr 05, 2012 at 14:05:31 -0400:
> On Apr 5, 2012 6:46 AM, "Philip Martin" <philip.martin_at_wandisco.com> wrote:
> >
> > Branko Čibej <brane_at_apache.org> writes:
> >
> > >> ... I think I may have identified the problem. The patch below checks
> > >> that the error struct is allocated and released by the same thread.
> > >> With the worker MPM the assertion always passes but with the event MPM
> I
> > >> get assertion failures. I don't fully understand the effect this would
> > >> have but I suspect it explains the problem.
> > >
> > > I think this pretty much explains what you're seeing.
> >
> > Yes. Thread A allocates the memory, stores the address in the
> > thread-specific data, sets the refcount to one and sets up the pool
> > cleanup handler. Thread A finishes with the request. Thread B runs the
> > pool cleanup handler, sets the refcount to zero, frees the memory and
> > sets the *wrong* thread-specific data to NULL. Thread A then gets the
> > free'd address from the thread-specific data and continues to use
> > it--all sorts of horrible things follow.
> >
> > I've raised issue 4157 to track this problem.
>
> Can we at least implement a detection for this situation and fail to start?
> Maybe mod_dav_svn would query the mpm type, and the fs type. We could at
> least backport that to 1.7.x pretty quickly.
>
No need. 1.7.x doesn't compile against 2.4 for other reasons (API
changes). I've patched them on trunk but vetoed the backport pending
resolution of the BDB hangs.
> Cheers,
> -g
Received on 2012-04-05 20:10:58 CEST