Daniel Stenberg wrote:
> On Wed, 8 Apr 2009, Toshio Kuratomi wrote:
>
>> I ran valgrind --leak-check=full --show-reachable=yes ./break
>>
>> ControlC'd after 100 iterations.
>
> Reduce the loop counter instead and let it finish on its own, as your
> control-c made it skip cleanups that (falsely) get reported as "leaks"
> there.
>
Thanks. So this is what I get when I turn the loop counter down to 100
iterations:

==28398== 48 bytes in 2 blocks are possibly lost in loss record 6 of 15
==28398== at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==28398== by 0x75FBDC7: PR_Malloc (in /lib/libnspr4.so)
==28398== by 0x75F2D8B: (within /lib/libnspr4.so)
==28398== by 0x760D123: (within /lib/libnspr4.so)
==28398== by 0x760E562: PR_Socket (in /lib/libnspr4.so)
==28398== by 0x760E6ED: PR_NewTCPSocket (in /lib/libnspr4.so)
==28398== by 0x6DB8EC1: Curl_nss_connect (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6DB033E: Curl_ssl_connect (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6D8F869: Curl_http_connect (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6D969C0: Curl_protocol_connect (in
/usr/lib/libcurl.so.4.1.1)
==28398== by 0x6D9BDA9: Curl_connect (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6DA4A78: Curl_perform (in /usr/lib/libcurl.so.4.1.1)
==28398==
==28398== 160 bytes in 2 blocks are definitely lost in loss record 9 of 15
==28398== at 0x4004BA2: calloc (vg_replace_malloc.c:397)
==28398== by 0x75FC039: PR_Calloc (in /lib/libnspr4.so)
==28398== by 0x4605923: (within /lib/libnsspem.so)
==28398== by 0x460599A: (within /lib/libnsspem.so)
==28398== by 0x4605836: (within /lib/libnsspem.so)
==28398== by 0x45F762B: (within /lib/libnsspem.so)
==28398== by 0x4603153: (within /lib/libnsspem.so)
==28398== by 0x45F0970: (within /lib/libnsspem.so)
==28398== by 0x6C68572: (within /lib/libnss3.so)
==28398== by 0x6C68B97: (within /lib/libnss3.so)
==28398== by 0x6C7BFDA: SECMOD_LoadModule (in /lib/libnss3.so)
==28398== by 0x6C7C222: SECMOD_LoadUserModule (in /lib/libnss3.so)
==28398==
==28398== 1,584 bytes in 99 blocks are definitely lost in loss record 12
of 15
==28398== at 0x4006AEE: malloc (vg_replace_malloc.c:207)
==28398== by 0x75FBDC7: PR_Malloc (in /lib/libnspr4.so)
==28398== by 0x6C29677: PORT_Alloc_Util (secport.c:113)
==28398== by 0x6C7818B: PK11_CreateGenericObject (in /lib/libnss3.so)
==28398== by 0x6DB8948: nss_load_cert (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6DB944B: Curl_nss_connect (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6DB033E: Curl_ssl_connect (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6D8F869: Curl_http_connect (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6D969C0: Curl_protocol_connect (in
/usr/lib/libcurl.so.4.1.1)
==28398== by 0x6D9BDA9: Curl_connect (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6DA4A78: Curl_perform (in /usr/lib/libcurl.so.4.1.1)
==28398== by 0x6DA57A2: curl_easy_perform (in /usr/lib/libcurl.so.4.1.1)
==28398==
==28398== 56,626,774 bytes in 246,213 blocks are possibly lost in loss
record 15 of 15
==28398== at 0x4004BA2: calloc (vg_replace_malloc.c:397)
==28398== by 0x75FC039: PR_Calloc (in /lib/libnspr4.so)
==28398== by 0x46054AF: (within /lib/libnsspem.so)
==28398== by 0x45F1F6B: (within /lib/libnsspem.so)
==28398== by 0x45F394D: (within /lib/libnsspem.so)
==28398== by 0x45F53CD: (within /lib/libnsspem.so)
==28398== by 0x45F97F3: (within /lib/libnsspem.so)
==28398== by 0x46012C8: (within /lib/libnsspem.so)
==28398== by 0x45F04AB: (within /lib/libnsspem.so)
==28398== by 0x6C77ECD: (within /lib/libnss3.so)
==28398== by 0x6C7814F: PK11_CreateGenericObject (in /lib/libnss3.so)
==28398== by 0x6DB8948: nss_load_cert (in /usr/lib/libcurl.so.4.1.1)
==28398==
==28398== LEAK SUMMARY:
==28398== definitely lost: 1,744 bytes in 101 blocks.
==28398== possibly lost: 56,626,822 bytes in 246,215 blocks.
==28398== still reachable: 407,606 bytes in 341 blocks.
==28398== suppressed: 0 bytes in 0 blocks.

13 iterations has the same results but lower values for the latter two.
 So if I'm reading this right, the a problem is in the Fedora libnss.

/me starts going through patches there.

-Toshio