Re: AW: [ANN] Apache Tomcat 11.0.23 Available

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.

Mark