Bugs item #3408783, was opened at 2011-09-13 18:14
Message generated for change (Comment added) made by rudlof
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3408783&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: None
Status: Pending
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Stephan Rudlof (rudlof)
Assigned to: Daniel Stenberg (bagder)
Summary: [SuSE] mem leaks visible in valgrind

Initial Comment:
Followup to ID: 3370249

Seem to be problems in libs used by cURL, not by cURL itself (but developers should know better).
Problems does not show up in Debian 6.0.2.

Attached are files to reproduce the problem (unzip, make and run from CL).
Currently worst mem leak (100 GETs without reuse of connection):
==2104== HEAP SUMMARY:
==2104== in use at exit: 71,308 bytes in 2,553 blocks
==2104== total heap usage: 148,223 allocs, 145,670 frees, 86,232,716 bytes allocated
==2104==
==2104== 2,100 bytes in 100 blocks are definitely lost in loss record 556 of 563
==2104== at 0x4C261D7: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==2104== by 0x6071A1B: CRYPTO_malloc (in /usr/lib64/libcrypto.so.0.9.8)
==2104== by 0x60A7784: BUF_strndup (in /usr/lib64/libcrypto.so.0.9.8)
==2104== by 0x5D745D9: ssl3_ctrl (in /usr/lib64/libssl.so.0.9.8)
==2104== by 0x4E54944: ossl_connect_common (in /home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==2104== by 0x4E54A24: Curl_ossl_connect (in /home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==2104== by 0x4E675D1: Curl_ssl_connect (in /home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==2104== by 0x4E3FBC1: Curl_http_connect (in /home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==2104== by 0x4E49879: Curl_protocol_connect (in /home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==2104== by 0x4E49F37: Curl_setup_conn (in /home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==2104== by 0x4E4C942: Curl_connect (in /home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==2104== by 0x4E5B082: Curl_do_perform (in /home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==2104==
==2104== LEAK SUMMARY:
==2104== definitely lost: 2,100 bytes in 100 blocks
==2104== indirectly lost: 0 bytes in 0 blocks
==2104== possibly lost: 0 bytes in 0 blocks
==2104== still reachable: 69,208 bytes in 2,453 blocks
==2104== suppressed: 0 bytes in 0 blocks

Couldn\'t trigger the name resolution related leaks in ID: 3370249 with this test program, though (have to check, if workaround is needed anymore).

Best regards,
Stephan

nfldevvip1:~/ViP/MemLeak: ./local/bin/curl -V

curl 7.21.7 (x86_64-unknown-linux-gnu) libcurl/7.21.7 OpenSSL/0.9.8h zlib/1.2.3
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: Largefile NTLM SSL libz

SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 1
Linux nfldevvip1 2.6.32.45-0.3-default #1 SMP 2011-08-22 10:12:58 +0200 x86_64 x86_64 x86_64 GNU/Linux

----------------------------------------------------------------------

Comment By: Stephan Rudlof (rudlof)
Date: 2011-09-15 14:29

Message:
Update:
If compiled with
  #define ALWAYS_NEW_CONNECTION 0 (Main.cpp) (does reuse connection, so
less mem leaks than in original test)
  #define WITH_ECS 1 (HTTPConnection.cpp) (uses certificates needing more
ssl)
and used with certificates (needed for getting this test running
correctly), there is a *big* difference between
  valgrind --leak-check=full --log-file=/tmp/vgECS.txt ./memLeakTest
https://nfldevvipecs.rus.uni-stuttgart.de/numlab/exercises/233751 100
and
  valgrind --leak-check=full --log-file=/tmp/vgECSIP.txt ./memLeakTest
https://129.69.8.244/numlab/exercises/233751 100
:

First
------
==20851== HEAP SUMMARY:
==20851== in use at exit: 72,608 bytes in 2,553 blocks
==20851== total heap usage: 44,144 allocs, 41,591 frees, 73,078,250
bytes allocated
==20851==
==20851== 3,400 bytes in 100 blocks are definitely lost in loss record 560
of 563
==20851== at 0x4C261D7: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20851== by 0x6071A1B: CRYPTO_malloc (in
/usr/lib64/libcrypto.so.0.9.8)
==20851== by 0x60A7784: BUF_strndup (in /usr/lib64/libcrypto.so.0.9.8)
==20851== by 0x5D745D9: ssl3_ctrl (in /usr/lib64/libssl.so.0.9.8)
==20851== by 0x4E54944: ossl_connect_common (in
/home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==20851== by 0x4E54A24: Curl_ossl_connect (in
/home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==20851== by 0x4E675D1: Curl_ssl_connect (in
/home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==20851== by 0x4E3FBC1: Curl_http_connect (in
/home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==20851== by 0x4E49879: Curl_protocol_connect (in
/home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==20851== by 0x4E49F37: Curl_setup_conn (in
/home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==20851== by 0x4E4C942: Curl_connect (in
/home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==20851== by 0x4E5B082: Curl_do_perform (in
/home/ruslof/ViP/MemLeak/local/lib/libcurl.so.4.2.0)
==20851==
==20851== LEAK SUMMARY:
==20851== definitely lost: 3,400 bytes in 100 blocks
==20851== indirectly lost: 0 bytes in 0 blocks
==20851== possibly lost: 0 bytes in 0 blocks
==20851== still reachable: 69,208 bytes in 2,453 blocks
==20851== suppressed: 0 bytes in 0 blocks

Second
----------
==20850== HEAP SUMMARY:
==20850== in use at exit: 69,208 bytes in 2,453 blocks
==20850== total heap usage: 43,745 allocs, 41,292 frees, 73,047,843
bytes allocated
==20850==
==20850== LEAK SUMMARY:
==20850== definitely lost: 0 bytes in 0 blocks
==20850== indirectly lost: 0 bytes in 0 blocks
==20850== possibly lost: 0 bytes in 0 blocks
==20850== still reachable: 69,208 bytes in 2,453 blocks
==20850== suppressed: 0 bytes in 0 blocks
==20850== Reachable blocks (those to which a pointer was found) are not
shown.

This is the reason, why I furthermore need the mem leak workaround
mentioned in ID: 3370249.

Seems to be same problem as above, but consuming much more bytes.
Think this can be interesting for other users of cURL; in spite of cURL
not being the reason for that (as bagder has said).

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2011-09-13 19:02

Message:
This is an OpenSSL problem afaik, not a libcurl problem and there's no fix
to be done in libcurl.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3408783&group_id=976
Received on 2011-09-15