Greg Stein wrote on Thu, Apr 05, 2012 at 14:05:31 -0400: > On Apr 5, 2012 6:46 AM, "Philip Martin" <philip.mar...@wandisco.com> wrote: > > > > Branko Čibej <br...@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
