Re: AW: [ANN] Apache Tomcat 11.0.23 Available

On 22/06/2026 15:58, Mark Thomas wrote:
> On 22/06/2026 15:31, Mark Thomas wrote:
>> On 22/06/2026 13:22, Thomas Hoffmann (Speed4Trade GmbH) via users wrote:
>>> Hello Mark,
>>>
>>> after upgrading from 11.0.22 to 11.0.23 I got a core dump during 
>>> startup:
>>>
>>> Stack: [0x00007514e1100000,0x00007514e1200000], 
>>> sp=0x00007514e11fd370,  free space=1012k
>>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
>>> C=native code)
>>> C  [libapr-1.so.0+0x20370]  apr_pool_create_ex+0x150
>>> C  [libtcnative-2.so.0.0.13+0xaefa] 
>>> Java_org_apache_tomcat_jni_Pool_create+0x3a
>>> j  org.apache.tomcat.util.net.openssl.OpenSSLEngine.<clinit>()V+35
>>> v  ~StubRoutines::call_stub 0x00007514c7d37cc6
>>> V  [libjvm.so+0x915134]  JavaCalls::call_helper(JavaValue*, 
>>> methodHandle const&, JavaCallArguments*, JavaThread*)+0x2f4
>>> V  [libjvm.so+0x8e9545] 
>>> InstanceKlass::call_class_initializer(JavaThread*)+0x265
>>> V  [libjvm.so+0x8eb22f] 
>>> InstanceKlass::initialize_impl(JavaThread*)+0x62f
>>> V  [libjvm.so+0xb6a013]  
>>> LinkResolver::resolve_field(fieldDescriptor&, LinkInfo const&, 
>>> Bytecodes::Code, bool, JavaThread*)+0x3b3
>>> V  [libjvm.so+0xb6a4ce] 
>>> LinkResolver::resolve_field_access(fieldDescriptor&, 
>>> constantPoolHandle const&, int, methodHandle const&, Bytecodes::Code, 
>>> JavaThread*)+0x5e
>>> V  [libjvm.so+0x90c99c] 
>>> InterpreterRuntime::resolve_get_put(JavaThread*, Bytecodes::Code)+0x1cc
>>> V  [libjvm.so+0x90d4a5] 
>>> InterpreterRuntime::resolve_from_cache(JavaThread*, 
>>> Bytecodes::Code)+0xe5
>>> j 
>>> org.apache.tomcat.util.net.openssl.OpenSSLUtil.getImplementedProtocols()Ljava/util/Set;+0
>>> j  org.apache.tomcat.util.net.SSLUtilBase.<init>(Lorg/apache/tomcat/ 
>>> util/net/SSLHostConfigCertificate;Z)V+26
>>> j  org.apache.tomcat.util.net.SSLUtilBase.<init>(Lorg/apache/tomcat/ 
>>> util/net/SSLHostConfigCertificate;)V+3
>>> j  org.apache.tomcat.util.net.openssl.OpenSSLUtil.<init>(Lorg/apache/ 
>>> tomcat/util/net/SSLHostConfigCertificate;)V+2
>>> j 
>>> org.apache.tomcat.util.net.openssl.OpenSSLImplementation.getSSLUtil(Lorg/apache/tomcat/util/net/SSLHostConfigCertificate;)Lorg/apache/tomcat/util/net/SSLUtil;+5
>>> j  org.apache.tomcat.util.net.AbstractEndpoint.createSSLContext(Lorg/ 
>>> apache/tomcat/util/net/SSLHostConfig;)V+89
>>> j  org.apache.tomcat.util.net.AbstractEndpoint.initialiseSsl()V+54
>>> j  org.apache.tomcat.util.net.NioEndpoint.bind()V+17
>>> j  org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup()V+1
>>> j  org.apache.tomcat.util.net.AbstractEndpoint.init()V+8
>>> j  org.apache.coyote.AbstractProtocol.init()V+169
>>> j  org.apache.coyote.http11.AbstractHttp11Protocol.init()V+57
>>> j  org.apache.catalina.connector.Connector.initInternal()V+159
>>> j  org.apache.catalina.util.LifecycleBase.init()V+29
>>> ....
>>>
>>> Upgrading tcnative from 2.0.13 to 2.0.15 fixed it for me.
>>> Just in case somebody else has similar issue.
>>
>> The minimum Tomcat Native version was increased to 2.0.15 for 11.0.23.
>>
>> The core dump shouldn't have happened but it looks like running with 
>> 2.0.13 triggers the core dump before Tomcat has a chance to realise an 
>> incorrect version of Native is being used. Not sure why at this point.
>>
>> Something to look into.
> 
> You'll see this if you try and force Tomcat to use 
> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation" when an invalid version of Tomcat Native is configured.
> 
> I'll see if I can find a cleaner way to handle this.

I need to clean up the patch, add some comments, add a changelog entry 
etc but from 11.0.24 onwards you'll see an ISE rather than a core dump 
for this in future.

Mark