Jeff Trawick <[EMAIL PROTECTED]> writes: > > Diff to previous 1.19 (colored) > > apr_bucket_alloc_create() now registers a cleanup that does a > > apr_bucket_alloc_destroy(). Don't double free by calling it explicitly. > > --------------------------------------------------------------- > > > > In this case, it was that the apr_bucket_alloc_t was created in pconn. > > The newly-added cleanup on pconn would destroy the apr_bucket_alloc_t. > > Then an explicit call to apr_bucket_alloc_destroy *after* destroying pconn > > would result in a double-free at best or an immediate segfault at worst. > > And I don't see that any change like is necessary on the worker MPM > side.
But if I make a change to worker to get rid of the apr_bucket_alloc_destroy() I can't reproduce the problem. What is happening is that the thread's pool is getting cleaned up before the thread goes away (baaaad) since the thread pool is a subpool of pchild and pchild can go away before the thread with a graceful restart. When this happens, the cleanup for the bucket_alloc_t is run when pchild goes away, so by the time apr_bucket_alloc_destroy() is called the storage has been released. At the moment, the right fix seems to be for a thread pool to be stand-alone, but I'd guess there are at least 10 reasons I can't think of for why that is a stupid idea :) Also, it would be nice if the apr_bucket_alloc code followed the usual pattern for destroy/cleanup (see apr_file_close() for an example, where we call apr_pool_cleanup_run()). It works as-is, but you have to stare at it for a while :) -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
