Bug#584968: libcurl3 / curl package appears to memory leak
Johnny Luong
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.
/**
~ * Compile: g++ -lcurl -o test test.cpp
~ */
#include <curl/curl.h>
int main(void)
{
curl_global_init(CURL_GLOBAL_ALL);
CURL * curl = curl_easy_init();
if (curl)
{
curl_easy_setopt(curl, CURLOPT_URL, "https://www.google.com/");
CURLcode res = curl_easy_perform(curl);
if (res != CURLE_OK)
{
printf("GET unsuccessful.\n");
}
curl_easy_cleanup(curl);
}
curl_global_cleanup();
return 0;
}
johnny@spike:~/deb$ g++ -lcurl -o test test.cpp
johnny@spike:~/deb$ valgrind --leak-check=full ./test
.
.
.
.
.
.
==26948== ERROR SUMMARY: 9 errors from 5 contexts (suppressed: 27 from 2)
==26948== malloc/free: in use at exit: 385 bytes in 9 blocks.
==26948== malloc/free: 2,988 allocs, 2,979 frees, 267,696 bytes allocated.
==26948== For counts of detected errors, rerun with: -v
==26948== searching for pointers to 9 not-freed blocks.
==26948== checked 634,000 bytes.
==26948==
==26948==
==26948== 15 bytes in 1 blocks are definitely lost in loss record 1 of 3
==26948== at 0x4C2260E: malloc (vg_replace_malloc.c:207)
==26948== by 0x65F08F2: CRYPTO_malloc (in /usr/lib/libcrypto.so.0.9.8)
==26948== by 0x6646883: BUF_strndup (in /usr/lib/libcrypto.so.0.9.8)
==26948== by 0x634C395: ssl3_ctrl (in /usr/lib/libssl.so.0.9.8)
==26948== by 0x4E47576: (within /usr/lib/libcurl.so.4.1.0)
==26948== by 0x4E47824: (within /usr/lib/libcurl.so.4.1.0)
==26948== by 0x4E37E0B: (within /usr/lib/libcurl.so.4.1.0)
==26948== by 0x4E3E101: (within /usr/lib/libcurl.so.4.1.0)
==26948== by 0x4E40B74: (within /usr/lib/libcurl.so.4.1.0)
==26948== by 0x4E4E80A: (within /usr/lib/libcurl.so.4.1.0)
==26948== by 0x40090E: main (in /home/johnny/deb/test)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkwNdaEACgkQg7TIS7A9iscaswCeJyplaJpW1XRlbAf+Pd7XhKfF
OQ4AnAzjEMP+7TgsWtlbRpGUbIW4Orzc
=1rKe
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Alessandro Ghedini
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'