memory leak due to CERT lookup



17 years ago
11 years ago


(Reporter: jeff, Assigned: julien.pierre)



Windows 2000

Firefox Tracking Flags

(Not tracked)



(2 attachments)



17 years ago
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.

Comment 1

17 years ago
Created attachment 45307 [details]
Win32 code to call the function

Comment 2

17 years ago
Created attachment 45308 [details]
gnu makefile for test code

Comment 3

17 years ago
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.

Comment 4

17 years ago
Assigned the bug to Kirk.
Assignee: wtc → kirke
Priority: -- → P2
Target Milestone: --- → 3.4

Comment 5

17 years ago
Marking NEW.
Ever confirmed: true
Keywords: mlk, patch, review


17 years ago
Blocks: 92580


17 years ago
No longer blocks: 92580

Comment 6

17 years ago
Changed the QA contact to Bishakha.
QA Contact: sonja.mirtitsch → bishakhabanerjee

Comment 7

17 years ago
Set target milestone to NSS 3.5.
Target Milestone: 3.4 → 3.5

Comment 8

17 years ago
Set target milestone to NSS 3.6.
Target Milestone: 3.5 → 3.6


16 years ago
Target Milestone: 3.6 → 3.7

Comment 9

16 years ago
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 → ---

Comment 11

16 years ago
Not likely to get to this in the 3.9 timeframe.
Set Target Milestone to Future.
Target Milestone: --- → Future


16 years ago
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?

Comment 13

15 years ago
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


11 years ago
Assignee: nobody → julien.pierre.boogz

Comment 14

11 years ago
I ran the test program against the current tip with dbx check leaks, and found no leaks. Closing WORKSFORME.
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.