valgrind reporting memory in use - expected?

Ian Pilcher <[email protected]>
Newsgroups gmane.comp.mozilla.crypto
Message-ID <[email protected]>
I'm working on a C program that uses libnss to update certificates in a
mod_nss database.  Using valgrind to check for memory leaks, and I am
seeing 8 blocks that are still in use when the program exits, all of
which were apparently allocated by NSS_InitReadWrite().

> ==6798== HEAP SUMMARY:
> ==6798==     in use at exit: 1,382 bytes in 8 blocks
> ==6798==   total heap usage: 1,777 allocs, 1,769 frees, 565,345 bytes allocated
> ==6798== 
> ==6798== 6 bytes in 1 blocks are still reachable in loss record 1 of 8
> ==6798==    at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
> ==6798==    by 0x5075B33: _PR_InitLinker (prlink.c:192)
> ==6798==    by 0x507BCE2: _PR_InitStuff (prinit.c:206)
> ==6798==    by 0x507C491: _PR_ImplicitInitialization (prinit.c:219)
> ==6798==    by 0x507C491: PR_CallOnce (prinit.c:774)
> ==6798==    by 0x54BED76: nss_Init (nssinit.c:580)
> ==6798==    by 0x54BFC18: NSS_InitReadWrite (nssinit.c:832)
> ==6798==    by 0x404828: init_libnss (umn.c:1191)
> ==6798==    by 0x40552C: main (umn.c:1424)
> ==6798== 
> ==6798== 24 bytes in 1 blocks are still reachable in loss record 2 of 8
> ==6798==    at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
> ==6798==    by 0x507BAB2: PR_ErrorInstallTable (prerrortable.c:169)
> ==6798==    by 0x507BD11: _PR_InitStuff (prinit.c:212)
> ==6798==    by 0x507C491: _PR_ImplicitInitialization (prinit.c:219)
> ==6798==    by 0x507C491: PR_CallOnce (prinit.c:774)
> ==6798==    by 0x54BED76: nss_Init (nssinit.c:580)
> ==6798==    by 0x54BFC18: NSS_InitReadWrite (nssinit.c:832)
> ==6798==    by 0x404828: init_libnss (umn.c:1191)
> ==6798==    by 0x40552C: main (umn.c:1424)
> ==6798== 
> ==6798== 24 bytes in 1 blocks are still reachable in loss record 3 of 8
> ==6798==    at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
> ==6798==    by 0x507BAB2: PR_ErrorInstallTable (prerrortable.c:169)
> ==6798==    by 0x507C4A1: PR_CallOnce (prinit.c:778)
> ==6798==    by 0x66678D6: NSS_InitializePRErrorTable (errstrs.c:38)
> ==6798==    by 0x54BF10B: nss_InitModules (nssinit.c:380)
> ==6798==    by 0x54BF10B: nss_Init (nssinit.c:689)
> ==6798==    by 0x54BFC18: NSS_InitReadWrite (nssinit.c:832)
> ==6798==    by 0x404828: init_libnss (umn.c:1191)
> ==6798==    by 0x40552C: main (umn.c:1424)
> ==6798== 
> ==6798== 32 bytes in 1 blocks are still reachable in loss record 4 of 8
> ==6798==    at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
> ==6798==    by 0x603066E: _dlerror_run (dlerror.c:141)
> ==6798==    by 0x602FFA1: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
> ==6798==    by 0x5076903: pr_FindSymbolInProg (prmem.c:98)
> ==6798==    by 0x5076903: _PR_InitZones (prmem.c:154)
> ==6798==    by 0x507BBA2: _PR_InitStuff (prinit.c:144)
> ==6798==    by 0x507C491: _PR_ImplicitInitialization (prinit.c:219)
> ==6798==    by 0x507C491: PR_CallOnce (prinit.c:774)
> ==6798==    by 0x54BED76: nss_Init (nssinit.c:580)
> ==6798==    by 0x54BFC18: NSS_InitReadWrite (nssinit.c:832)
> ==6798==    by 0x404828: init_libnss (umn.c:1191)
> ==6798==    by 0x40552C: main (umn.c:1424)
> ==6798== 
> ==6798== 40 bytes in 1 blocks are still reachable in loss record 5 of 8
> ==6798==    at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
> ==6798==    by 0x5075B21: _PR_InitLinker (prlink.c:190)
> ==6798==    by 0x507BCE2: _PR_InitStuff (prinit.c:206)
> ==6798==    by 0x507C491: _PR_ImplicitInitialization (prinit.c:219)
> ==6798==    by 0x507C491: PR_CallOnce (prinit.c:774)
> ==6798==    by 0x54BED76: nss_Init (nssinit.c:580)
> ==6798==    by 0x54BFC18: NSS_InitReadWrite (nssinit.c:832)
> ==6798==    by 0x404828: init_libnss (umn.c:1191)
> ==6798==    by 0x40552C: main (umn.c:1424)
> ==6798== 
> ==6798== 64 bytes in 1 blocks are still reachable in loss record 6 of 8
> ==6798==    at 0x4C2DB9D: malloc (vg_replace_malloc.c:299)
> ==6798==    by 0x50849B2: PR_NewCondVar (ptsynch.c:321)
> ==6798==    by 0x54BE61C: nss_doLockInit (nssinit.c:539)
> ==6798==    by 0x507C4A1: PR_CallOnce (prinit.c:778)
> ==6798==    by 0x54BED76: nss_Init (nssinit.c:580)
> ==6798==    by 0x54BFC18: NSS_InitReadWrite (nssinit.c:832)
> ==6798==    by 0x404828: init_libnss (umn.c:1191)
> ==6798==    by 0x40552C: main (umn.c:1424)
> ==6798== 
> ==6798== 168 bytes in 1 blocks are still reachable in loss record 7 of 8
> ==6798==    at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
> ==6798==    by 0x508490C: PR_NewLock (ptsynch.c:142)
> ==6798==    by 0x54BE608: nss_doLockInit (nssinit.c:535)
> ==6798==    by 0x507C4A1: PR_CallOnce (prinit.c:778)
> ==6798==    by 0x54BED76: nss_Init (nssinit.c:580)
> ==6798==    by 0x54BFC18: NSS_InitReadWrite (nssinit.c:832)
> ==6798==    by 0x404828: init_libnss (umn.c:1191)
> ==6798==    by 0x40552C: main (umn.c:1424)
> ==6798== 
> ==6798== 1,024 bytes in 1 blocks are still reachable in loss record 8 of 8
> ==6798==    at 0x4C2FA50: calloc (vg_replace_malloc.c:711)
> ==6798==    by 0x5075702: _PR_InitTPD (prtpd.c:65)
> ==6798==    by 0x507BC96: _PR_InitStuff (prinit.c:172)
> ==6798==    by 0x507C491: _PR_ImplicitInitialization (prinit.c:219)
> ==6798==    by 0x507C491: PR_CallOnce (prinit.c:774)
> ==6798==    by 0x54BED76: nss_Init (nssinit.c:580)
> ==6798==    by 0x54BFC18: NSS_InitReadWrite (nssinit.c:832)
> ==6798==    by 0x404828: init_libnss (umn.c:1191)
> ==6798==    by 0x40552C: main (umn.c:1424)
> ==6798== 
> ==6798== LEAK SUMMARY:
> ==6798==    definitely lost: 0 bytes in 0 blocks
> ==6798==    indirectly lost: 0 bytes in 0 blocks
> ==6798==      possibly lost: 0 bytes in 0 blocks
> ==6798==    still reachable: 1,382 bytes in 8 blocks
> ==6798==         suppressed: 0 bytes in 0 blocks

I am currently calling NSS_Shutdown(), PL_ArenaFinish(), and
PR_Cleanup() during program shutdown.

Is there anything else I should be doing to clean up?

-- 
========================================================================
Ian Pilcher                                         [email protected]
-------- "I grew up before Mark Zuckerberg invented friendship" --------
========================================================================

-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.