Before committing I gave it a second thought. My theory is motivated by
the crash around main_log we fixed in 2007. There we learned, that on i5
the two initialization passes of httpd are done in the same process. We
also saw, that the pool pconf got invalidated after the first pass. That
was a problem for the global static main_log, because we allocated it
from pconf, and if the pointer was not NULL, we didn't allocate it again
during the second initialization and instead used its now invalid contents.

In the file mod_jk.c there is no other memory allocated from an apr pool
in the first initialization run and reused in the second.

Outside of mod_jk.c we use apr pools only in jk_resolve() in file
jk_connect.c. And yes, again it is based on pconf!

So what happens is, that the static apr pool jk_apr_pool in jk_connect.c
is created as a sub pool of pconf during the first init run, and then
destroyed at the beginning of the second init run when pconf gets
cleared. During the second init run we then reuse jk_apr_pool although
it is destroyed and not valid any more. So the patch I sent should be
OK, because it doesn't reuse the pool, but it would be more correct to
register a cleanup, that invalidates the pointer to the pool. I'l see
how that goes and maybe send you that as a patch too.

Regards,

Rainer

On 12.05.2009 17:55, Henri Gomez wrote:
>> http://svn.eu.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_connect.c?r1=706039&r2=745136&diff_format=h
>>
>> Don't know exactly, what was Mladens motivation for it, but the locally
>> created and destroyed pool will release resources as well.
>>
>> Thanks for reporting and breaking it down to jk_resolve() and the pool.
> 
> Thanks to you for the quick fix.
> 
> Hope to be the only one with this problem but I suspect Windows and
> Unix threaded implementations may be also affected ;(

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to