Closed Bug 94614 Opened 23 years ago Closed 17 years ago

memory leak due to CERT lookup


(NSS :: Libraries, defect, P2)

Windows 2000


(Not tracked)



(Reporter: jeff, Assigned: julien.pierre)


(Keywords: memory-leak)


(2 files)

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
decreases the reference count to 1.  then the call to
    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

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.
Assignee: wtc → kirke
Priority: -- → P2
Target Milestone: --- → 3.4
Marking NEW.
Ever confirmed: true
Keywords: mlk, patch, review
Blocks: 92580
No longer blocks: 92580
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee
Set target milestone to NSS 3.5.
Target Milestone: 3.4 → 3.5
Set target milestone to NSS 3.6.
Target Milestone: 3.5 → 3.6
Target Milestone: 3.6 → 3.7
Moved to target milestone 3.8 because the original
NSS 3.7 release has been renamed 3.8.
Target Milestone: 3.7 → 3.8
Remove target milestone of 3.8, since these bugs didn't get into that release.
Target Milestone: 3.8 → ---
Not likely to get to this in the 3.9 timeframe.
Set Target Milestone to Future.
Target Milestone: --- → Future
Target Milestone: Future → ---

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 
Assignee: kirk.erickson → wchang0222
QA Contact: bishakhabanerjee → jason.m.reid
Assignee: wtchang → nobody
QA Contact: jason.m.reid → libraries
Assignee: nobody → julien.pierre.boogz
I ran the test program against the current tip with dbx check leaks, and found no leaks. Closing WORKSFORME.
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.