Bug 1115952

Description of problem:

While running pcp upstream testsuite I stepped on to these valgrind warning about possible memory leak (a bit condensed "reproducer"):


[root@ibm-x3550m3-01 ~]# cat main.c
int main(int argc, char **argv)
{
        return 0;
}

[root@ibm-x3550m3-01 ~]# 
[root@ibm-x3550m3-01 ~]# 
[root@ibm-x3550m3-01 ~]# gcc -Wall -O2 -g main.c -o main -lfreebl3 -lnspr4
[root@ibm-x3550m3-01 ~]# 
[root@ibm-x3550m3-01 ~]# 
[root@ibm-x3550m3-01 ~]# valgrind --leak-check=full --read-var-info=yes ./main
==952== Memcheck, a memory error detector
==952== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==952== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==952== Command: ./main
==952== 
==952== 
==952== HEAP SUMMARY:
==952==     in use at exit: 6,904 bytes in 70 blocks
==952==   total heap usage: 159 allocs, 89 frees, 64,755 bytes allocated
==952== 
==952== 40 bytes in 1 blocks are possibly lost in loss record 33 of 63
==952==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==952==    by 0x33A180D60B: _PR_Getfd (prfdcach.c:112)
==952==    by 0x33A1825094: pt_SetMethods (ptio.c:3303)
==952==    by 0x33A1825468: PR_OpenFile (ptio.c:3581)
==952==    by 0x339FC2B9D7: blapi_SHVerifyFile (shvfy.c:356)
==952==    by 0x339FC2BD6E: blapi_SHVerify (shvfy.c:290)
==952==    by 0x339FC16338: bl_startup_tests (fipsfreebl.c:1541)
==952==    by 0x339FC54E55: ??? (in /lib64/libfreebl3.so)
==952==    by 0x339FC039C2: ??? (in /lib64/libfreebl3.so)
==952== 
==952== 48 bytes in 1 blocks are possibly lost in loss record 37 of 63
==952==    at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==952==    by 0x33A180D5F9: _PR_Getfd (prfdcach.c:109)
==952==    by 0x33A1825094: pt_SetMethods (ptio.c:3303)
==952==    by 0x33A1825468: PR_OpenFile (ptio.c:3581)
==952==    by 0x339FC2B9D7: blapi_SHVerifyFile (shvfy.c:356)
==952==    by 0x339FC2BD6E: blapi_SHVerify (shvfy.c:290)
==952==    by 0x339FC16338: bl_startup_tests (fipsfreebl.c:1541)
==952==    by 0x339FC54E55: ??? (in /lib64/libfreebl3.so)
==952==    by 0x339FC039C2: ??? (in /lib64/libfreebl3.so)
==952== 
==952== LEAK SUMMARY:
==952==    definitely lost: 0 bytes in 0 blocks
==952==    indirectly lost: 0 bytes in 0 blocks
==952==      possibly lost: 88 bytes in 2 blocks
==952==    still reachable: 6,816 bytes in 68 blocks
==952==         suppressed: 0 bytes in 0 blocks
==952== Reachable blocks (those to which a pointer was found) are not shown.
==952== To see them, rerun with: --leak-check=full --show-reachable=yes
==952== 
==952== For counts of detected and suppressed errors, rerun with: -v
==952== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
[root@ibm-x3550m3-01 ~]# 

After some digging into the code my initial idea about what's going on was that some fd closing calls in blapi_SHVerifyFile are missing _PR_Putfd() call somewhere. Well, I think I found it in stubs.c finally, so this probably is not the case. Also "possibly lost" warning can be caused by some pointer manipulation as mentioned in valgrind docs ([1]) and does not necessary mean there is actual memory leak. In that case it would be good if someone more familiar with nss-softtokn/nspr sources call it false positive, then we could make valgrind ignore this and not to disturb pcp testsuite any longer.


Version-Release number of selected component (if applicable):

nspr-4.10.6-1.el6
nss-softokn-3.14.3-14.el6


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

[1] http://valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks