libcurl / gnutls memory leak

Bug #1552284 reported by Sandis Neilands
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Linux Mint

Bug Description

The default libcurl package uses gnutls 2.2 as TLS backend. The current GnuTLS version 3.4 so I hesitated to open a ticket in their tracker. Feel free to push this issue upstream to Ubuntu -> Debian -> GnuTLS if you can reproduce it with a recent version of GnuTLS.

1) Linux Mint 17.2 / 17.3 (MATE edition).

2) The attached sample program uses libcurl to retrieve a page from Wikipedia. Valgrind shows that there is a use of uninitialised variable and memory leak in gnutls.

$ sudo time valgrind --tool=memcheck --read-var-info=yes --track-origins=yes --leak-check=full --leak-check=full ./leak 1 1
==10288== Memcheck, a memory error detector
==10288== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==10288== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==10288== Command: ./leak 1 1
==10288== Conditional jump or move depends on uninitialised value(s)
==10288== at 0x5B518DD: gnutls_session_get_data (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4E80909: gtls_connect_step3 (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4E80E19: gtls_connect_common (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4E818DF: Curl_ssl_connect_nonblocking (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4E450DD: https_connecting (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4E678E0: multi_runsingle (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4E68530: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4E5FC92: curl_easy_perform (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4009F4: main (leak.c:60)
==10288== Uninitialised value was created by a stack allocation
==10288== at 0x4E801F0: gtls_connect_step3 (in /usr/lib/x86_64-linux-gnu/
==10288== HEAP SUMMARY:
==10288== in use at exit: 4,617 bytes in 77 blocks
==10288== total heap usage: 3,738,177 allocs, 3,738,100 frees, 522,604,011 bytes allocated
==10288== 48 bytes in 12 blocks are definitely lost in loss record 13 of 22
==10288== at 0x4C2AB80: malloc (in /usr/lib/valgrind/
==10288== by 0x5B6F91E: pkcs11_add_module (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x5B6FEC3: gnutls_pkcs11_init (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x5B5A49F: gnutls_global_init (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4E80AB8: Curl_gtls_init (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x4E5F97C: curl_global_init (in /usr/lib/x86_64-linux-gnu/
==10288== by 0x400A28: main (leak.c:42)
==10288== LEAK SUMMARY:
==10288== definitely lost: 48 bytes in 12 blocks
==10288== indirectly lost: 0 bytes in 0 blocks
==10288== possibly lost: 0 bytes in 0 blocks
==10288== still reachable: 4,569 bytes in 65 blocks
==10288== suppressed: 0 bytes in 0 blocks
==10288== Reachable blocks (those to which a pointer was found) are not shown.
==10288== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==10288== For counts of detected and suppressed errors, rerun with: -v
==10288== ERROR SUMMARY: 8 errors from 2 contexts (suppressed: 0 from 0)
Command terminated by signal 2
43.81user 0.18system 1:15.12elapsed 58%CPU (0avgtext+0avgdata 257204maxresident)k
0inputs+24outputs (0major+54042minor)pagefaults 0swaps

3) Memory leak.

4) No memory leak.

5) The problem occurs always.

Revision history for this message
Sandis Neilands (sandis-neilands) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers