Mark,

On 2/9/24 08:30, Mark Thomas wrote:
On 09/02/2024 12:14, Rémy Maucherat wrote:
On Fri, Feb 9, 2024 at 12:46 PM Mark Thomas <ma...@apache.org> wrote:
On 08/02/2024 17:07, Mark Thomas wrote:

<snip/>

Back to working out a more robust fix...

While the fix worked well locally, it hasn't fixed the problem on the
Buildbot CI worker.

I'm going to take another look.

I had a look at the test output, and the issue is exclusively with the
APR connector (the tests are a bit weird so that the APR connector is
also run, basically the test is the same for all connectors), that's
why it would only affect 8.5 and 9.0. Overall it's not even certain
OpenSSL + NIO really needed a fix and the OpenSSLContext cleanup is
most likely good enough (at least in that case). Build 845 for 9.0.x
was crashing when using the APR connector, not NIO.

I am making progress. I have a slightly amended theory as to what is going on (and now confirmed via logging).

The clean-up of OpenSSLContext is performed by the finalizer.
In the problematic tests, the Native library is repeatedly loaded and unloaded within a single JVM. The crashes happen when the finalizer attempts to clean an OpenSSLContext instance from a previous load of the native library after the native library has been reloaded.

I have a fix for this.

I intend to:
- revert (most of) the changes made to 8.5.x through 11.0.x
- apply the new fix to 9.0.x and 8.5.x only

Apologies for the noise while I tracked the root cause of this down. The good news is that this should address one of the causes of unit test instability.

Apologies for the noise while I caught up to today's messages on this topic. You can obviously ignore all my critiques thus far.

Since this appears mostly to be due to the unit-testing environment, should we simply create a system property that suppresses the shutdown of the native library during unit-tests and let it stay configured the whole time? Or do we actually need to de-configure and re-configure it during the unit-test run?

-chris

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

Reply via email to