222707 - many leaked locks created by secmodCreateMutext

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Nelson Bolyard (seldom reads bugmail)]

I ran selfserv (3.9 trunk) with Purify.  I sent it a single https request,
which was GET /stop, which caused it to shutdown and exit.  There were 
128 memory blocks leaked, all belonging to PRLocks created by calls from
secmodCreateMutext().  

Here are some call stacks and other stats:

[W] MLK: Memory leak of 8448 bytes from 64 blocks allocated in PR_Calloc [NSPR4.DLL]
        Distribution of leaked blocks
              8448 bytes from 64 blocks of 132 bytes (first block: 0x0230d7f0) 
        Allocation location
            calloc         [MSVCRT.DLL]
            PR_Calloc      [prmem.c:484]
            PR_NewLock     [prulock.c:194]
            secmodCreateMutext [pk11load.c:61]
            nssToken_TraverseCertificates [devtoken.c:1647]
            NSSTrustDomain_TraverseCertificates [trustdomain.c:1052]
            PK11_TraverseSlotCerts [pk11cert.c:1072]
            CERT_GetSSLCACerts [certhigh.c:628]
            SSL_ConfigSecureServer [sslsecur.c:689]
[W] MLK: Memory leak of 8316 bytes from 63 blocks allocated in PR_Calloc [NSPR4.DLL]
        Distribution of leaked blocks
              8316 bytes from 63 blocks of 132 bytes (first block: 0x02302c80) 
        Allocation location
            calloc         [MSVCRT.DLL]
            PR_Calloc      [prmem.c:484]
            PR_NewLock     [prulock.c:194]
    secmodCreateMutext [pk11load.c:61]
    find_objects   [devtoken.c:416]
    find_objects_by_template [devtoken.c:536]
    nssToken_FindTrustForCertificate [devtoken.c:1277]
    nssTrustDomain_FindTrustForCertificate [trustdomain.c:1197]
    nssTrust_GetCERTCertTrustForCert [pki3hack.c:538]
    fill_CERTCertificateFields [pki3hack.c:704]
    stan_GetCERTCertificate [pki3hack.c:732]
    STAN_GetCERTCertificate [pki3hack.c:756]
    convert_cert   [pk11cert.c:97]
    nssPKIObjectCollection_Traverse [pkibase.c:893]
    NSSTrustDomain_TraverseCertificates [trustdomain.c:1060]
    PK11_TraverseSlotCerts [pk11cert.c:1072]
    CERT_GetSSLCACerts [certhigh.c:628]
    SSL_ConfigSecureServer [sslsecur.c:689]
[W] MLK: Memory leak of 132 bytes from 1 block allocated in PR_Calloc [NSPR4.DLL]
        Distribution of leaked blocks
               132 bytes from 1 block of 132 bytes (0x03114448) 
        Allocation location
            calloc         [MSVCRT.DLL]
            PR_Calloc      [prmem.c:484]
            PR_NewLock     [prulock.c:194]
            secmodCreateMutext [pk11load.c:61]
            pk11_FindObjectByTemplate [pk11cert.c:192]
            pk11_isRootSlot [pk11slot.c:2004]
            PK11_InitSlot  [pk11slot.c:2071]
            SECMOD_LoadPKCS11Module [pk11load.c:275]
            SECMOD_LoadModule [pk11pars.c:316]
            SECMOD_LoadModule [pk11pars.c:331]
            nss_Init       [nssinit.c:456]
            NSS_Initialize [nssinit.c:531]

Comment 1

[Wan-Teh Chang]

Assigned the bug to Bob.

Comment 2

[Robert Relyea]

Arrg, this is 2 years old!

secmodCreateMutext is only called from a PKCS #11 module, when it is passed as
one of the 4 mutex primitives. Softoken has never called create mutex, so it was
either a leak in nssckbi or a leak in another PKCS #11 module that was running
when the test ran. The latter is a little more likely since we don't have any
symbols for the PKCS 11 calls between the NSS and secmodCreateMutex (if the
problem were in softoken or nssckbi, you would have expected to see the
NSC_FindInit or C_FindInit symbols on the stack between Traverse or Find call
and the semodCreateMutext call.

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

This bug was created during the tail end of the NSS 3.9 development in late 
2003 where we were trying to fix all leaks and null pointer crashes identified 
by the NISCC tests.  I'm pretty sure I wasn't using any non-NSS PKCS11 modules 
in that test.  (Hmm. Is it possible that I was testing a certain USB-fob 
device at that time?)  In any case, I think there's enough info here with which
to attempt to reproduce it.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

The stacks in this 3.5 year old leak bug look quite similar to the stacks 
in bug 308275, for which I have a patch.  I wonder if they could be the 
same problem/cause.