https://bz.apache.org/bugzilla/show_bug.cgi?id=66669
--- Comment #7 from DigitalCat <digital...@huawei.com> --- We found the way to reproduce this issue。 Upgrading Tomcat Native Library 1.2.23 to Tomcat Native Library 1.2.33, we set the tomcat in apr mode, In a high-concurrency scenario, the Tomcat process crashes. When line 476 is commented out in native/src/sslcontext.c, the JVM crash does not occur. We gauss the content in servername is not released in line 192 in native/src/sslcontext.c, causing the JVM to crash. I hope you reply as soon as possible. Here's our analysis, and I hope it's helpful. First, the apr allocates and releases the memory of internal objects through malloc_pool. The allocated objects do not need to be released. When the memory pool is destroyed, all the objects allocated in the memory pool are destroyed and released. At the same time, the cleanup callback function registered in the memory pool is called back. The local invoking method for the Tomcat to create and destroy a memory pool is Pool.create,Pool.destory. When Tomcat functions as an HTTPS server, the SSLContext (org.apache.tomcat.util.net.openssl.OpenSSLContext#OpenSSLContext) is initialized using SSContext.make (native invoking) during startup. During server certificate initialization, an APR memory pool is created, The memory pool will be destroyed when the certificate is released. Check the invoking code. It is found that the memory pool destruction method is invoked in the org.apache.tomcat.util.net.AprEndpoint#unbind method. In normal cases, the memory pool is released when the endpoint is destroyed (destory) or stopped. PR based on GitHub https://github.com/apache/tomcat-native/commit/d1885c202d987f3898ba72b7fc084413f0bdb1f9 In this modification, the callback function ssl_callback_ClientHello is registered when SSLContext.make is used. This function is invoked when the SSL handshake is performed inside SSLSocket.handshake each time the client requests. The memory is allocated on the memory pool for each call, storing the servername, which is not shown here. It is suspected that memory leakage occurs before the apr memory pool destruction or cleanup method is invoked. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
