Am 24.01.2019 um 13:37 schrieb Mark Thomas:
On 24/01/2019 12:18, Rainer Jung wrote:
Am 21.01.2019 um 15:49 schrieb Mark Thomas:
Version 1.2.20 includes the following changes compared to 1.2.19:

- Fixed memory leak associated with the use of OpenSSL BIO (used when
    OpenSSL provides the TLS functionality for the NIO and NIO2
    connectors)

Various other fixes and improvements. See the changelog for details.

The proposed release artefacts can be found at [1],
and the build was done using tag [2].

The Apache Tomcat Native 1.2.20 release is
   [ ] Stable, go ahead and release
   [X] Broken because of ...

At last during unit test execution JVM crashes, eg. in TestCustomSsl. A
new native APR pool is being freed as a child pool of aprPool during
OpenSSLContext.destroy() at the end of a test and then there's another
attempt to free it later when the Finalizer kicks in and finalizes the
old OpenSSLEngine.

What I don't know though is whether this can happen for normal TC or
embedded TC or is specific to the lifetimes of objects during unit test
execution.

Details:

- test testCustomTrustManagerNone creates OpenSSLEngine 7f560c39, ssl
4298850656 and con->pool 4309969128 from parent pool aprPool = c->pool
4306893544

- at the end of this test OpenSSLContext.destroy() runs and destroys
aprPool = c->pool 4306893544 and therefore also its child pools
including con->pool 4309969128

- later during testCustomSslImplementation the Finalizer kicks in for
the old OpenSSLEngine 7f560c39.

- The finalize() method frees the old ssl 4298850656, which was also
created in the earlier test

- Freeing that ssl in the native code destroys the con->pool 4309969128
which was already destroyed at the end of the first test

It can happen in normal usage. I saw it once. It happens on Connector
stop so it could be worse. My memory leak fix is definitely the root
cause. Any thoughts on a possible fix?

Currently experimenting with a cleanup handler registered for con->pool. That can get an arbitrary argument and is called when the cleanup happens, especially useful for the problematic cleanup as a child pool. The handler could overwrite con->pool with NULL. But that would only make sense, if we are sure, that we are notgoing to use stuff after OpenSSLContext.destroy().

Regards,

Rainer


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

Reply via email to