Memory leak in CERT_LockCertTrust.

RESOLVED DUPLICATE of bug 399304

Status

NSS
Libraries
RESOLVED DUPLICATE of bug 399304
11 years ago
10 years ago

People

(Reporter: Slavomir Katuscak, Assigned: Julien Pierre)

Tracking

({memory-leak})

3.12
x86
Linux
memory-leak

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
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.
(Reporter)

Comment 1

11 years ago
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)

Updated

10 years ago
Assignee: nobody → julien.pierre.boogz
(Assignee)

Comment 4

10 years ago
This bug has the same cause as bug 399304 . Marking as duplicate.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 399304
(Assignee)

Comment 5

10 years ago
Wan-Teh,

Good catch ! My fix for bug 399304 however added that missing PZ_DestroyLock.
(Assignee)

Comment 6

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