conscrypt: Native memory leak introduced between version 1.0.1 and 1.1.0 and remains in the latest release.
Hi, It seems that between version 1.0.1 and 1.1.0 something has changed in conscrypt such that it now appears to leak memory when used as the SSL library with the jetty web server. The latest version of conscrypt also appears to leak memory.
To reproduce it start jetty with conscrypt then send http 1.0 requests, this can be done with curl.
Limit the cipher When only one of the following ciphers exist:
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 the memory leak still appears.
Number of java classes
I does not look to ever be garbage collected, I made the JVM allocate a bunch of byte[] held on to by a weak reference and call System.gc a bunch but that did not reduce the RSS of the JVM.
running jmap gives:
num #instances #bytes class name
----------------------------------------------
510: 111 5328 org.conscrypt.NativeSslSession$Impl
692: 111 2664 org.conscrypt.ByteArray
693: 111 2664 org.conscrypt.NativeRef$SSL_SESSION
1577: 5 400 org.conscrypt.SSLParametersImpl
1751: 13 312 org.conscrypt.HostProperties$Architecture
1805: 3 288 org.conscrypt.ConscryptEngine
1806: 12 288 org.conscrypt.HostProperties$Architecture
...
10127: 1 16 org.conscrypt.PeerInfoProvider$1
It doesn’t look like an insane amount of classes are created.
Compile with debug
I have a memory profiler (jemalloc), however it only shows that something in the conscrypt shared library is allocating. I would like to try conscrypt with -g and -O0 so I can hopefully get some line numbers on the allocations. I couldn’t find pre-compiled boringSSL with debug symbols. I attempted to compile it myself, however after tinkering
CMakeLists.txt
- set(C_CXX_FLAGS "-Werror -Wformat=2 -Wsign-compare -Wmissing-field-initializers -Wwrite-strings")
+ set(C_CXX_FLAGS "-Wformat=2 -Wsign-compare -Wmissing-field-initializers -Wwrite-strings")
I ran:
$ cmake -DCMAKE_POSITION_INDEPENDENT_CODE=TRUE -DCMAKE_ASM_FLAGS=-Wa,--noexecstack -GNinja ..
...
-- Configuring done
-- Generating done
-- Build files have been written to: /home/luke/code/third_party/boringssl/build64
After I ran:
$ ninja
[444/444] Linking CXX executable ssl/ssl_test
I set: BORINGSSL_HOME=/home/luke/code/third_party/boringssl/
I then attempted to build conscrypt, with some minor modifications I replaced all -O3 with -O0 and -g.
./gradlew install
./gradlew build
This resulted in building a linux conscrypt I included that and started jetty web server with that along with jemalloc, however the resulting pdf: jemalloc.pdf doesn’t show anything interesting about conscrypt or boringSSL.
It is not clear what to do next, to help identify why conscrypt is leaking memory.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 22 (2 by maintainers)
Commits related to this issue
- Avoid holding a GlobalRef to ALPN selector The ALPN selector code used to hold a GlobalRef for the callback. This appeared to make it impossible to discard the ref since there wasn't any trigger for ... — committed to kruton/conscrypt by kruton 5 years ago
- Avoid holding a GlobalRef to ALPN selector The ALPN selector code used to hold a GlobalRef for the callback. This appeared to make it impossible to discard the ref since there wasn't any trigger for ... — committed to prbprbprb/conscrypt by kruton 5 years ago
- Avoid holding a GlobalRef to ALPN selector The ALPN selector code used to hold a GlobalRef for the callback. This appeared to make it impossible to discard the ref since there wasn't any trigger for ... — committed to prbprbprb/conscrypt by kruton 5 years ago
NB, I’ll cherry pick the fix for this into the 2.3.0 branch which should finally be done early next week.
ah is something not going well it looks like 2.3.0 is not yet released.
is this fix in a current release? thank you
Also worth looking at Android’s own malloc debugging, maybe via a wrap script.
If jetty isn’t unusably slow when running with
leak_trackthen there might be some insights from the logged stack traces.You should be able to get a debug build by adding
-gto the compiler args in openjdk/build.gradle. Does that not work? Running under something like jemalloc might also be helpful. Or if you can find a reproducible case we’d be happy to take a look as well.