Am 25.08.2017 um 23:25 schrieb Rainer Jung:
Am 25.08.2017 um 18:24 schrieb Mark Thomas:
Version 1.2.13 includes the following changes compared to 1.2.12:
- Update minimum recommended OpenSSL version to 1.0.2l
- Update minimum recommended APR version to 1.6.2
- Windows binaries built with OpenSSL 1.0.2l and APR 1.6.2
- Support for the SSL_CONF_cmd API
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.13 is
[ ] Stable, go ahead and release
[ ] Broken because of ...
Partial result: although tests in general look good until now, I found
one unit test specific problem on Linux using the APR connector and
OpenSSL 1.0.2.
The new test TestDefaultServletEncoding in TC 9 head executes many test
cases. All of them use the same Tomcat child process, but each test case
runs org.apache.catalina.core.AprLifecycleListener.initializeSSL() which
goes down to the native initialize() in native/src/ssl.c. There we
create a thread local using apr_threadkey_private_create() which in turn
calls pthread_key_create(). That pthread API is limited to creating not
more than PTHREAD_KEYS_MAX keys. On typical linux systems this limit is
1024, but the test runs initializeSSL() for about 2600 times. the first
1024 succeed, the remaining ones throw an exception in initializeSSL()
with errno EAGAIN (which is expected when getting above the limit).
On Solaris the limit is 128 but the problem does not occur. When using
OpenSSL 1.1.0 and above, that part of the native code doesn't run and
the problem also does not show up, the same for Windows. And for JSSE
connectors with OpenSSL impl the AprLifecycleListener only calls
initializeSSL() in the SSL related tests, so not for
TestDefaultServletEncoding in contrast to the APR connector.
I'd expect the initializeSSL() call for real TC and other tcnative using
apps is only called once or at least not extremely often, so that should
not be a problem outside of our unit tests. Still it would be nice if we
could add a cleanup using apr_threadkey_private_delete() somewhere.
Unfortunately in order to be able to call a cleanup from TC code, e.g.
the AprLifecycleListener, we would need an API extension in tcnative first.
Concerning the problem of the thread key cleanup: test
TestDefaultServletEncoding already calls
AprLifecycleListener.terminateAPR() during each encoding test, which in
turn calls Library.terminate(), which does the cleanup of the global
pool and executes the registered ssl clean up function
ssl_init_cleanup(). We could add the clean up of the thread_exit_key
there. For example the following patch works:
Index: native/src/ssl.c
===================================================================
--- native/src/ssl.c (revision 1806205)
+++ native/src/ssl.c (working copy)
@@ -52,6 +52,7 @@
#if ! (defined(WIN32) || defined(WIN64))
apr_threadkey_t *thread_exit_key;
+static int threadkey_initialized = 0;
#endif
#endif
@@ -331,6 +332,12 @@
return APR_SUCCESS;
ssl_initialized = 0;
+#if OPENSSL_VERSION_NUMBER < 0x10100000L && ! (defined(WIN32) ||
defined(WIN64))
+ if (threadkey_initialized) {
+ threadkey_initialized = 0;
+ apr_threadkey_private_delete(thread_exit_key);
+ }
+#endif
if (tcn_password_callback.cb.obj) {
JNIEnv *env;
tcn_get_java_env(&env);
@@ -766,6 +773,7 @@
tcn_ThrowAPRException(e, err);
return (jint)err;
}
+ threadkey_initialized = 1;
#endif
/* Initialize thread support */
ssl_thread_setup(tcn_global_pool);
Unfortunately that would be a change to tcnative, so we would have to do
another tag. I would prefer to include this fix in the release.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
