there's a memory leak with respect to certificates. this may be a loop of structures pointing to each other. i'll try to explain as best i can. when PK11_FindCertFromNickname() is called, the CERTCertificate that is returned has 2 references -- one that we have and one that is being held by the internal pk11_slot[] data structure in security/nss/lib/softoken/pkcs11u.c. after the application calls CERT_DestroyCertificate(), the count goes to 1 as expected. also, the CERTCertificate holds a reference to the PK11SlotInfo. (the reference count on the PK11SlotInfo is 2 because of this reference and the one that the module holds.) (the module is the "nss internal pkcs #11 module".) in SECMOD_Shutdown(): the reference count on the internal module is 2 because of the direct reference "internalModule" and the one from the module list "modules". so, the call to SECMOD_DestroyModule(internalModule) decreases the reference count to 1. then the call to SECMOD_DestroyModule(element->module) via SECMOD_DestroyModuleElement(... via SECMOD_DestroyModuleList(modules) reaches the loop calling PK11_FreeSlot(). [on my system, this is the second module in the list and the second slot in that module.] in PK11_FreeSlot() the reference count is decremented from 2 to 1 and the call returns -- rather than calling PK11_DestroySlot(). since PK11_DestroySlot() does not get called, none of the PK11Slot cleanup gets done (the session stuff) and PK11_FreeSlotCerts() does not get called. so we end up leaking a CERTCertificate and PK11SlotInfo (and a bunch of other subordinate structures). i also noticed that there is no explicit method of cleaning up the members of the pk11_slot[] data structure in security/nss/lib/softoken/pkcs11u.c -- it looks like some of the fields may get indirectly deleted via a wrapper PK11SlotInfo but i'm not sure. i'm sorry to babble like this in a bug report, but i've stared at this one for 2 days and am not sure of anything any more.... i'll attach a test case in a minute.

when the block marked #if 1 is present, i'm seeing a bunch of leaks totaling about 25kb that aren't present when the block is #if 0'd.

Assigned the bug to Kirk.

Marking NEW.

Changed the QA contact to Bishakha.

Set target milestone to NSS 3.5.

Set target milestone to NSS 3.6.

Moved to target milestone 3.8 because the original NSS 3.7 release has been renamed 3.8.

Remove target milestone of 3.8, since these bugs didn't get into that release.

Not likely to get to this in the 3.9 timeframe. Set Target Milestone to Future.

Jeff, You originally reported this bug against NSS 3.3. Do you still use NSS 3.3? Are you able to use NSS 3.9? We fixed MANY memory leaks in NSS 3.9, and I suspect it is possible that the leak you reported may be gone now. Can you test with NSS 3.9 and confirm whether this is still an issue, or not?

Sorry, I'm not working on code base that used NSS any longer (it was a contract project), so I can't upgrade and try 3.9. You might try running the test program that I included under BoundsChecker with and without the #if-1 block and see what happens.

I ran the test program against the current tip with dbx check leaks, and found no leaks. Closing WORKSFORME.