cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Help tracking down libcurl + nss memory leak

From: Toshio Kuratomi <a.badger_at_gmail.com>
Date: Thu, 09 Apr 2009 21:43:12 -0700

Daniel Stenberg wrote:
> On Thu, 9 Apr 2009, Daniel Stenberg wrote:
>
>> rv = PK11_CreateGenericObject(slot, theTemplate, 4, PR_FALSE /* isPerm
>> */);
>>
>> The 'rv' variable is just forgotten... that can't be right!
>
> Attached to this mail is my first take at addressing the leaked "generic
> objects". This seems to fix the problems I see, but there might of
> course be more problems lurking. Let me know how it works for you!
>
Thanks! Tested this patch and it has mixed success. On the one hand,
it cuts the definitely leaked memory in half so it's doing what it's
supposed to. OTOH, it increases the size of the possibly leaked objects
by about the same amount (I'm thinking it's for storing the extra pointers).

Figuring out where the possibly lost memory is going is what's going to
help the most. At 13 requests, it stands at 6MB. At 100, it's 56MB.
The library method I have this curl call in gets called multiple times
for each request that I'm processing so the memory quickly adds up.

New valgrind output attached.

-Toshio

==21781==
==21781== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 70 from 1)
==21781== malloc/free: in use at exit: 6,102,707 bytes in 24,901 blocks.
==21781== malloc/free: 39,596 allocs, 14,695 frees, 19,155,498 bytes allocated.
==21781== For counts of detected errors, rerun with: -v
==21781== searching for pointers to 24,901 not-freed blocks.
==21781== checked 6,570,636 bytes.
==21781==
==21781== 48 bytes in 2 blocks are possibly lost in loss record 6 of 14
==21781== at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==21781== by 0x75FBDC7: PR_Malloc (in /lib/libnspr4.so)
==21781== by 0x75F2D8B: (within /lib/libnspr4.so)
==21781== by 0x760D123: (within /lib/libnspr4.so)
==21781== by 0x760E562: PR_Socket (in /lib/libnspr4.so)
==21781== by 0x760E6ED: PR_NewTCPSocket (in /lib/libnspr4.so)
==21781== by 0x4066E82: Curl_nss_connect (in /usr/lib/libcurl.so.4.1.1)
==21781== by 0x405E382: Curl_ssl_connect (in /usr/lib/libcurl.so.4.1.1)
==21781== by 0x403D8A9: Curl_http_connect (in /usr/lib/libcurl.so.4.1.1)
==21781== by 0x4044A00: Curl_protocol_connect (in /usr/lib/libcurl.so.4.1.1)
==21781== by 0x4049DE9: Curl_connect (in /usr/lib/libcurl.so.4.1.1)
==21781== by 0x4052AB8: Curl_perform (in /usr/lib/libcurl.so.4.1.1)
==21781==
==21781==
==21781== 160 bytes in 2 blocks are definitely lost in loss record 9 of 14
==21781== at 0x4004BA2: calloc (vg_replace_malloc.c:397)
==21781== by 0x75FC039: PR_Calloc (in /lib/libnspr4.so)
==21781== by 0x4786923: error_get_my_stack (error.c:145)
==21781== by 0x478699A: nss_ClearErrorStack (error.c:281)
==21781== by 0x4786836: NSSArena_Create (arena.c:385)
==21781== by 0x477862B: nssCKFWInstance_Create (instance.c:217)
==21781== by 0x4784153: NSSCKFWC_Initialize (wrap.c:205)
==21781== by 0x4771970: pemC_Initialize (nssck.api:117)
==21781== by 0x421D572: secmod_ModuleInit (pk11load.c:146)
==21781== by 0x421DB97: SECMOD_LoadPKCS11Module (pk11load.c:378)
==21781== by 0x4230FDA: SECMOD_LoadModule (pk11pars.c:323)
==21781== by 0x4231222: SECMOD_LoadUserModule (pk11pars.c:391)
==21781==
==21781==
==21781== 6,019,636 bytes in 24,721 blocks are possibly lost in loss record 14 of 14
==21781== at 0x4004BA2: calloc (vg_replace_malloc.c:397)
==21781== by 0x75FC039: PR_Calloc (in /lib/libnspr4.so)
==21781== by 0x47864AF: nss_ZAlloc (arena.c:892)
==21781== by 0x4772F6B: CreateObject (pinst.c:215)
==21781== by 0x477494D: pem_CreateObject (pobject.c:1071)
==21781== by 0x47763CD: pem_mdSession_CreateObject (psession.c:156)
==21781== by 0x477A7F3: nssCKFWSession_CreateObject (session.c:1353)
==21781== by 0x47822C8: NSSCKFWC_CreateObject (wrap.c:1991)
==21781== by 0x47714AB: pemC_CreateObject (nssck.api:566)
==21781== by 0x422CECD: PK11_CreateNewObject (pk11obj.c:412)
==21781== by 0x422D14F: PK11_CreateGenericObject (pk11obj.c:1346)
==21781== by 0x4066915: nss_load_cert (in /usr/lib/libcurl.so.4.1.1)
==21781==
==21781== LEAK SUMMARY:
==21781== definitely lost: 160 bytes in 2 blocks.
==21781== possibly lost: 6,019,684 bytes in 24,723 blocks.
==21781== still reachable: 82,863 bytes in 176 blocks.
==21781== suppressed: 0 bytes in 0 blocks.
==21781== Reachable blocks (those to which a pointer was found) are not shown.
==21781== To see them, rerun with: --leak-check=full --show-reachable=yes

Received on 2009-04-10