From bugsplat: malloc [rtlib.o] calloc [rtlib.o] PR_Calloc [prmem.c:64] PORT_ZAlloc [utilsecport.c:152] pk11_pbe_decode [pk11wrappk11slot.c:3352] PK11_ParamFromAlgid [pk11wrappk11slot.c:3510] PK11_PBEKeyGen [pk11wrappk11skey.c:4075] 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. Thank you! ------- 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 separable enough.
A fix is checked in to NSS_3_3_BRANCH. to pk11slot.c
r=wtc. (pk11slot.c, rev. 220.127.116.11)