The leak here is because the SECITEM_ZFreeItem free the Mech->data but this is
already a structure with More indirections... The salt is not freed and leaks 36
bytes every call.
------- Additional Comments From wtc Oct-30-2001 06:56 -------
We don't use scopus/bugsplat for NSS bugs any more.
The NSS bug database is now bugzilla.mozilla.org.
Would you mind filing this bug at bugzilla.mozilla.org?
You'll need to go to http://bugzilla.mozilla.org/createaccount.cgi
to open a Bugzilla account for yourself first. Then
go to http://bugzilla.mozilla.org/enter_bug.cgi to file
a bug report against NSS.
------- Additional Comments From mhein Oct-30-2001 11:43 -------
I'll open the mozilla bug for you.
Bob, could you please take a look at this memory leak
report and determine the "severity" of this leak?
Does the PK11_PBEKeyGen function get called many times
by a typical client of NSS?
This memory leak should be evaluated for NSS 3.3.2.
I got more information from the bug reporter.
The memory leak is an increasing memory leak. It leaks
every time he calls the PK11_PBEKeyGen function.
PBE keygen is not called very often in a 'typical' client. It is usually used to
unwrap private keys in pk12util, however I know a few people are using them to
generate fixed keys use to wrap passwords (usually to allow unattended restart).
I do have a fix for some memory leaks in the PBE code, and this one sounds
familiar, but they are on the 3.4 code base. I think the section it's in is
A fix is checked in to NSS_3_3_BRANCH. to pk11slot.c
r=wtc. (pk11slot.c, rev. 220.127.116.11)