retitle 584968 libssl1.0.0: memory leak in load_builtin_compressions forwarded 584968 http://rt.openssl.org/Ticket/Display.html?id=2561&user=guest&pass=guest reassign 584968 libssl1.0.0 1.0.0f-1 kthxbye
Hi, On Mon, Jun 07, 2010 at 03:41:37PM -0700, Johnny Luong wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Package: libcurl3 > Version: 7.18.2-8lenny4 > > It's not clear to me but the library appears to leak memory; using the > command line tool appears to leak as well. This is on Debian Lenny > using the AMD64 port. > > [...] This is what valgrind reports as of libcurl3 v7.23.1-3 and libssl1.0.0 v1.0.0f-1: ==25191== HEAP SUMMARY: ==25191== in use at exit: 88 bytes in 3 blocks ==25191== total heap usage: 3,016 allocs, 3,013 frees, 148,896 bytes allocated ==25191== ==25191== 24 bytes in 1 blocks are still reachable in loss record 1 of 3 ==25191== at 0x4C27673: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25191== by 0x65F8B83: CRYPTO_malloc (mem.c:306) ==25191== by 0x636993B: load_builtin_compressions (ssl_ciph.c:435) ==25191== by 0x636B7F8: SSL_COMP_get_compression_methods (ssl_ciph.c:1689) ==25191== by 0x63708A7: SSL_library_init (ssl_algs.c:134) ==25191== by 0x4E567F2: Curl_ossl_init (ssluse.c:689) ==25191== by 0x4E5E1FD: curl_global_init (easy.c:229) ==25191== by 0x40833D: ??? (in /usr/bin/curl) ==25191== by 0x40267E: ??? (in /usr/bin/curl) ==25191== by 0x54D3EAC: (below main) (libc-start.c:228) ==25191== ==25191== 32 bytes in 1 blocks are still reachable in loss record 2 of 3 ==25191== at 0x4C27673: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25191== by 0x65F8B83: CRYPTO_malloc (mem.c:306) ==25191== by 0x66621CE: sk_new (stack.c:125) ==25191== by 0x6369919: load_builtin_compressions (ssl_ciph.c:432) ==25191== by 0x636B7F8: SSL_COMP_get_compression_methods (ssl_ciph.c:1689) ==25191== by 0x63708A7: SSL_library_init (ssl_algs.c:134) ==25191== by 0x4E567F2: Curl_ossl_init (ssluse.c:689) ==25191== by 0x4E5E1FD: curl_global_init (easy.c:229) ==25191== by 0x40833D: ??? (in /usr/bin/curl) ==25191== by 0x40267E: ??? (in /usr/bin/curl) ==25191== by 0x54D3EAC: (below main) (libc-start.c:228) ==25191== ==25191== 32 bytes in 1 blocks are still reachable in loss record 3 of 3 ==25191== at 0x4C27673: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==25191== by 0x65F8B83: CRYPTO_malloc (mem.c:306) ==25191== by 0x66621EC: sk_new (stack.c:127) ==25191== by 0x6369919: load_builtin_compressions (ssl_ciph.c:432) ==25191== by 0x636B7F8: SSL_COMP_get_compression_methods (ssl_ciph.c:1689) ==25191== by 0x63708A7: SSL_library_init (ssl_algs.c:134) ==25191== by 0x4E567F2: Curl_ossl_init (ssluse.c:689) ==25191== by 0x4E5E1FD: curl_global_init (easy.c:229) ==25191== by 0x40833D: ??? (in /usr/bin/curl) ==25191== by 0x40267E: ??? (in /usr/bin/curl) ==25191== by 0x54D3EAC: (below main) (libc-start.c:228) ==25191== ==25191== LEAK SUMMARY: ==25191== definitely lost: 0 bytes in 0 blocks ==25191== indirectly lost: 0 bytes in 0 blocks ==25191== possibly lost: 0 bytes in 0 blocks ==25191== still reachable: 88 bytes in 3 blocks ==25191== suppressed: 0 bytes in 0 blocks ==25191== ==25191== For counts of detected and suppressed errors, rerun with: -v ==25191== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 10 from 6) The memory leak originally reported seems to have been fixed or it can't be reproduced (I suspect it has been fixed in the libssl 0.9.8 -> 1.0.0 update but I didn't test this). The leak above is caused by the fact the the compression algorithms allocated in the load_builtin_compressions function do not get freed, and has been already reported upstream [0] [1] (hence reassigning to the libssl package). Cheers [0] http://rt.openssl.org/Ticket/Display.html?id=2561&user=guest&pass=guest [1] http://rt.openssl.org/Ticket/Display.html?id=2439&user=guest&pass=guest -- perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse' -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
