Julien,
Ok thanks. I'm stuck with NSS 3.4.2 for now. And I still have what looks
like a memory leak somewhere (could very well be somewhere else in my app).
I understand you're saying that the virtual memory size of my app may not
decrease, but in my case, it grows over time...I just want to rule out the
CRL operations.
So here are a few follow-up questions. First, here's a code snippet showing
a simpler form of the function (checkCRL) that I repeatedly call in my app
(Note that NSS is initialized before I call this function):
--- start code snippet ---
function checkCRL() {
char *crlFile = myCRLFile.crl;
PRFileDesc *inFile
SECItem crlDER = {0,0,0};
CERTSignedCrl *signedCrl;
CERTCertificate *issuerCert;
CERTCrl *crl;
/* Open the CRL file */
inFile = PR_Open( crlFile, PR_RDONLY, 0 );
/* Read in the der content */
rv = ReadDERFromFile( crlDER, inFile, PR_FALSE );
/* Decode the CRL */
signedCrl = CERT_DecodeDERCrl( NULL, crlDER, crlType );
/* Find the crl issuer name */
issuerCert = CERT_FindCertByName( CERT_GetDefaultCertDB(),
signedCrl-crl.derName );
/* If issuerCert is a v3 certificate, make sure that it can be used for crl
signing purpose */
rv = CERT_CheckCertUsage ( issuerCert, KU_CRL_SIGN );
/* Verify the issuer signature on the CRL */
rv = CERT_VerifySignedData( signedCrl-signatureWrap, issuerCert, PR_Now(),
NULL );
/* Get a reference to the CRL entries */
crl = signedCrl-crl;
... parse through the crl revocation list to check on a particular cert
serial number...
PR_Close( inFile );
CERT_DestroyCertificate( issuerCert );
PORT_Free( crlDER.data );
SEC_DestroyCrl( signedCrl );
}
--- end code snippet ---
Note that in CERT_DecodeDERCrl(), I specify NULL for the PRArenaPool
object. Is that OK?
Also, when I free the memory for the crlDER object, should I call
SECITEM_FreeItem( crlDER, PR_TRUE ) or is calling PORT_Free( crlDER.data )
enough?
-- POC
-Original Message-
From: Julien Pierre [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 7:31 PM
To: [EMAIL PROTECTED]
Subject: Re: CERT_DecodeDERCrl
Patrick,
Cesard, Patrick O. wrote:
Julien,
No, I'm not sure the leak is related to CERT_DecodeDERCrl. But I know I'm
still using NSS 3.4.2.
Also, I'm calling ReadDERFromFile() before I do the crl decoding. This
function puts the der bytes into a SECItem object (call it crlDER).
I free the memory in that object with PORT_Free( crlDER.data ). I'm not
sure
if I even need to do this.
I notice that my app's virtual memory size (swap size) increases each time
I
read in a crl with ReadDERFromFile and then decode with CERT_DecodeDERCrl.
ReadDERFromFile is the same as SECU_ReadDERFromFile(). I borrowed it :)
Yes, you do need to free the data after the decode.
CERT_DecodeDERCrl actually copies the DER data to the new object. So
unless you free the DER you passed in, you will have two copies of the CRL.
This is likely why the virtual memory size of your process increases.
Note that on many operating systems, the virtual memory size will never
decrease. This isn't indicative of a memory leak, but rather of an
increased working set of the program.
If you don't want to have the two copies, which is unnecessary, you can
use the new function CERT_DecodeDERCRLWithFlags . I introduced this
function in NSS 3.6 . One of the flags is called
CRL_DECODE_DONT_COPY_DER . When you use it, the decode function will not
copy the input DER. Rather, your program will be responsible for
managing the memory allocated for the DER of the CRL . This means you
will need to keep that SECItem buffer allocated for as long as the
CERTSignedCrl object exists, and you should remember to free it right
after you call Sec_DestroyCrl . This is more complicated and prone to
programming errors, which is why it isn't the default setting. If you
are very concerned about the working set of your program and use very
large CRLs, however, this is the option you should use.
