On Thu, Sep 13, 2007 at 11:22:11AM +0300, Tacalau Daniel Stefan wrote: > Joe Orton wrote: > > I guess this is one part of the pool-debug code which never got tested! > > This can be fixed either by some convoluted hack to change the pool > > ownership after apr_thread_create(), or simply by moving the thread > > creation later in apr_thread_create(). The latter would be simpler. > > Can you file a bug on this in bugzilla? > > > > joe > > > Thread creation is the last operation done by apr_thread_create().
Sorry, I meant the other way round but that makes no sense either, so ignore me :) > A solution would be for apr_thread_exit() to not call > apr_pool_destroy() since it the exiting thread does now own the pool > and leave this to the thread parent. This will comply with > apr_pool_check_integrity requirements. > > How important is the apr_pool_check_integrity's owneship test (do not > release on a thread resources allocated in a pool that belongs to > another thread)? Can this lead to crashes or leaks? All this stuff is just debugging code, it doesn't necessarily imply a problem in a production build. This one aims to find places where a thread uses a pool created in another thread (generally unexpected, supposedly). You could just work around this passing a different argument to --enable-pool-debug so you don't get the APR_POOL_DEBUG_OWNER checks. Thanks for filing the PR. Regards, joe
