Closed Bug 399296 Opened 18 years ago Closed 18 years ago

Memory leak in CERT_LockCertTrust.

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Version:
3.12
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 399304

People

(Reporter: slavomir.katuscak+mozilla, Assigned: julien.pierre)

Details

(Keywords: memory-leak)

Yesterday I enabled PKIX testing on Linux tinderbox running memory leak tests. In OCSP tests (standard OCSP tests wrapped by Valgrind) I found this leak: ==27565== 88 bytes in 1 blocks are still reachable in loss record 37 of 60 ==27565== at 0x40056BF: calloc (vg_replace_malloc.c:279) ==27565== by 0x407F74C: PR_Calloc (prmem.c:474) ==27565== by 0x40907BE: PR_NewLock (ptsynch.c:174) ==27565== by 0x80D2ACB: __nss_InitLock (nsslocks.c:67) ==27565== by 0x80D2B48: nss_InitLock (nsslocks.c:82) ==27565== by 0x80B5FAE: CERT_LockCertTrust (certdb.c:2664) ==27565== by 0x80BE7D4: CERT_GetCertTrust (stanpcertdb.c:115) ==27565== by 0x81EC61C: pkix_pl_Pk11CertStore_CheckTrust (pkix_pl_pk11certstore.c:104) ==27565== by 0x8242B67: PKIX_PL_Cert_IsCertTrusted (pkix_pl_cert.c:3252) ==27565== by 0x80E65B3: pkix_Build_VerifyCertificate (pkix_build.c:1075) ==27565== by 0x80F5C19: pkix_BuildForwardDepthFirstSearch (pkix_build.c:2727) ==27565== by 0x81060B6: pkix_Build_InitiateBuildChain (pkix_build.c:4181) ==27565== by 0x81076B4: PKIX_BuildChain (pkix_build.c:4364) ==27565== by 0x80718B8: cert_BuildAndValidateChain (certvfypkix.c:755) ==27565== by 0x8073932: cert_VerifyCertChainPkix (certvfypkix.c:1141) ==27565== by 0x806A64A: cert_VerifyCertChain (certvfy.c:945) ==27565== by 0x806B18A: CERT_VerifyCertificate (certvfy.c:1362) ==27565== by 0x806B75B: CERT_VerifyCertificateNow (certvfy.c:1597) ==27565== by 0x80679C1: CERT_EnableOCSPDefaultResponder (ocsp.c:5218) ==27565== by 0x805083A: main (ocspclnt.c:1219) Seems that in CERT_LockCertTrust() there is global certTrustLock initialized when used for the first time, but is not destroyed on exit.
More stacks related to this bug (from strsclnt vs selfserv tests, strsclnt under Valgrind): ==24689== 88 bytes in 1 blocks are still reachable in loss record 24 of 60 ==24689== at 0x40056BF: calloc (vg_replace_malloc.c:279) ==24689== by 0x433F74C: PR_Calloc (prmem.c:474) ==24689== by 0x43507BE: PR_NewLock (ptsynch.c:174) ==24689== by 0x40E4FEB: __nss_InitLock (nsslocks.c:67) ==24689== by 0x40E5068: nss_InitLock (nsslocks.c:82) ==24689== by 0x40D23AE: CERT_LockCertTrust (certdb.c:2664) ==24689== by 0x40DABD4: CERT_GetCertTrust (stanpcertdb.c:115) ==24689== by 0x42DA82C: pkix_pl_Pk11CertStore_CheckTrust (pkix_pl_pk11certstore.c:104) ==24689== by 0x4222DD3: PKIX_PL_Cert_IsCertTrusted (pkix_pl_cert.c:3252) ==24689== by 0x41A7C9F: pkix_Build_VerifyCertificate (pkix_build.c:1075) ==24689== by 0x41B7305: pkix_BuildForwardDepthFirstSearch (pkix_build.c:2727) ==24689== by 0x41C77A2: pkix_Build_InitiateBuildChain (pkix_build.c:4181) ==24689== by 0x41C8DA0: PKIX_BuildChain (pkix_build.c:4364) ==24689== by 0x4096CD0: cert_BuildAndValidateChain (certvfypkix.c:755) ==24689== by 0x4098D4A: cert_VerifyCertChainPkix (certvfypkix.c:1141) ==24689== by 0x408FA62: cert_VerifyCertChain (certvfy.c:945) ==24689== by 0x408FAD5: CERT_VerifyCertChain (certvfy.c:957) ==24689== by 0x4090A91: CERT_VerifyCert (certvfy.c:1555) ==24689== by 0x4090BB1: CERT_VerifyCertNow (certvfy.c:1606) ==24689== by 0x40208F1: SSL_AuthCertificate (sslauth.c:254) ==24689== by 0x804BE7E: mySSLAuthCertificate (strsclnt.c:280) ==24689== by 0x402625D: ssl2_HandleServerHelloMessage (sslcon.c:2931) ==24689== by 0x402A3C4: ssl_Do1stHandshake (sslsecur.c:151) ==24689== by 0x402C572: ssl_SecureSend (sslsecur.c:1152) ==24689== by 0x40322C0: ssl_Send (sslsock.c:1432) ==24689== by 0x43356F0: PR_Send (priometh.c:226) ==24689== by 0x804CB25: handle_connection (strsclnt.c:696) ==24689== by 0x804D247: do_connects (strsclnt.c:887) ==24689== by 0x804C3DB: thread_wrapper (strsclnt.c:439) ==24689== by 0x4358734: _pt_root (ptthread.c:221) ==24689== by 0x805370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24689== by 0x66CFFD: clone (in /lib/tls/libc-2.3.4.so) ==24824== 88 bytes in 1 blocks are still reachable in loss record 24 of 60 ==24824== at 0x40056BF: calloc (vg_replace_malloc.c:279) ==24824== by 0x433F74C: PR_Calloc (prmem.c:474) ==24824== by 0x43507BE: PR_NewLock (ptsynch.c:174) ==24824== by 0x40E4FEB: __nss_InitLock (nsslocks.c:67) ==24824== by 0x40E5068: nss_InitLock (nsslocks.c:82) ==24824== by 0x40D23AE: CERT_LockCertTrust (certdb.c:2664) ==24824== by 0x40DABD4: CERT_GetCertTrust (stanpcertdb.c:115) ==24824== by 0x42DA82C: pkix_pl_Pk11CertStore_CheckTrust (pkix_pl_pk11certstore.c:104) ==24824== by 0x4222DD3: PKIX_PL_Cert_IsCertTrusted (pkix_pl_cert.c:3252) ==24824== by 0x41A7C9F: pkix_Build_VerifyCertificate (pkix_build.c:1075) ==24824== by 0x41B7305: pkix_BuildForwardDepthFirstSearch (pkix_build.c:2727) ==24824== by 0x41C77A2: pkix_Build_InitiateBuildChain (pkix_build.c:4181) ==24824== by 0x41C8DA0: PKIX_BuildChain (pkix_build.c:4364) ==24824== by 0x4096CD0: cert_BuildAndValidateChain (certvfypkix.c:755) ==24824== by 0x4098D4A: cert_VerifyCertChainPkix (certvfypkix.c:1141) ==24824== by 0x408FA62: cert_VerifyCertChain (certvfy.c:945) ==24824== by 0x408FAD5: CERT_VerifyCertChain (certvfy.c:957) ==24824== by 0x4090A91: CERT_VerifyCert (certvfy.c:1555) ==24824== by 0x4090BB1: CERT_VerifyCertNow (certvfy.c:1606) ==24824== by 0x40208F1: SSL_AuthCertificate (sslauth.c:254) ==24824== by 0x804BE7E: mySSLAuthCertificate (strsclnt.c:280) ==24824== by 0x401CCD2: ssl3_HandleCertificate (ssl3con.c:7119) ==24824== by 0x401E3FF: ssl3_HandleHandshakeMessage (ssl3con.c:7782) ==24824== by 0x401E7E8: ssl3_HandleHandshake (ssl3con.c:7898) ==24824== by 0x401F0BA: ssl3_HandleRecord (ssl3con.c:8161) ==24824== by 0x402018A: ssl3_GatherCompleteHandshake (ssl3gthr.c:206) ==24824== by 0x4022B36: ssl_GatherRecord1stHandshake (sslcon.c:1258) ==24824== by 0x402A3C4: ssl_Do1stHandshake (sslsecur.c:151) ==24824== by 0x402C572: ssl_SecureSend (sslsecur.c:1152) ==24824== by 0x40322C0: ssl_Send (sslsock.c:1432) ==24824== by 0x43356F0: PR_Send (priometh.c:226) ==24824== by 0x804CB25: handle_connection (strsclnt.c:696) ==24824== by 0x804D247: do_connects (strsclnt.c:887) ==24824== by 0x804C3DB: thread_wrapper (strsclnt.c:439) ==24824== by 0x4358734: _pt_root (ptthread.c:221) ==24824== by 0x805370: start_thread (in /lib/tls/libpthread-2.3.4.so) ==24824== by 0x66CFFD: clone (in /lib/tls/libc-2.3.4.so)
Keywords: mlk
Bob, is this new behavior in 3.12?
Slavo: These stacks all have a large part in common. There should be only one leak stack entry in the "ignored" file, and it should be similar to this: **/CERT_LockCertTrust/nss_InitLock/__nss_InitLock/PR_NewLock/PR_Calloc/calloc/**
Assignee: nobody → julien.pierre.boogz
This bug has the same cause as bug 399304 . Marking as duplicate.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
Wan-Teh, Good catch ! My fix for bug 399304 however added that missing PZ_DestroyLock.
Please ignore comment 5. It was supposed to be in another bug. As Wan-Teh found out, this bug does not have the same cause as bug 399304 . But the fix for bug 399304 fixes this bug also. So I'm leaving it as a duplicate.
You need to log in before you can comment on or make changes to this bug.