Last Comment Bug 404919 - memory leak in sftkdb_ReadSecmodDB() (sftkmod.c)
: memory leak in sftkdb_ReadSecmodDB() (sftkmod.c)
Status: RESOLVED FIXED
:
Product: NSS
Classification: Components
Component: Libraries (show other bugs)
: trunk
: x86 SunOS
: -- normal (vote)
: 3.12
Assigned To: nobody
:
Mentors:
: 401072 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-21 23:15 PST by Boying Lu
Modified: 2008-01-21 16:03 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch (362 bytes, patch)
2007-11-21 23:19 PST, Boying Lu
no flags Details | Diff | Review
mv label "bail" into the "if" block (458 bytes, patch)
2007-11-22 18:41 PST, Boying Lu
wtc: review+
Details | Diff | Review
mv label "bail" into the "if" block (as checked in) (668 bytes, patch)
2007-11-27 18:41 PST, Wan-Teh Chang
no flags Details | Diff | Review

Description Boying Lu 2007-11-21 23:15:19 PST
Using solaris memory leak detection tool libumem.so, I found a memory leak in sftkdb_ReadSecmodDB().  Here is the related output of libumem.so:
                 libumem.so.1`umem_cache_alloc_debug+0x14f
                 libumem.so.1`umem_cache_alloc+0x144
                 libumem.so.1`umem_alloc+0xc5
                 libumem.so.1`malloc+0x27
                 libnspr4.so`PR_Malloc+0x5d
                 libnspr4.so`GrowStuff+0x95
                 libnspr4.so`fill2+0xb7
                 libnspr4.so`cvt_s+0xc8
                 libnspr4.so`dosprintf+0xcdf
                 libnspr4.so`PR_vsmprintf+0x50
                 libnspr4.so`PR_smprintf+0x34
                 0xf8a1ae08
                 0xf8a1b48e
                 0xf89fe3c5
                 libnss3.so`SECMOD_GetModuleSpecList+0x42
                 libnss3.so`SECMOD_LoadModule+0x156
                 libnss3.so`nss_Init+0x270
                 libnss3.so`NSS_NoDB_Init+0x57
                 unsigned nsNSSComponent::InitializeNSS+0x18e
                 unsigned nsNSSComponent::Init+0x15a
                 unsigned nsNSSComponentConstructor+0x9f
                 libxpcom_core.so`unsigned nsGenericFactory::CreateInstance+0x46
                 ...
Test Case:
1. firefox -P
2. click "Exit" button
Comment 1 Boying Lu 2007-11-21 23:19:02 PST
Created attachment 289785 [details] [diff] [review]
patch
Comment 2 Wan-Teh Chang 2007-11-22 09:21:12 PST
Comment on attachment 289785 [details] [diff] [review]
patch

We also need to free olddbname at the other
exit points of the if block.

We can move the "bail" label into the if block,
and free olddbname there, like this:

bail:
        if (olddbname) {
            PR_smprintf_free(olddbname);
        }
    }
Comment 3 Boying Lu 2007-11-22 18:41:47 PST
Created attachment 289875 [details] [diff] [review]
mv label "bail" into the "if" block

Thanks for the comment. I re-made the patch
Comment 4 Wan-Teh Chang 2007-11-22 22:48:51 PST
Comment on attachment 289875 [details] [diff] [review]
mv label "bail" into the "if" block

r=wtc.

I will fix the indentation when I check in
the patch.  In NSS, we indent by four spaces.
Comment 5 Wan-Teh Chang 2007-11-27 18:41:18 PST
Created attachment 290488 [details] [diff] [review]
mv label "bail" into the "if" block (as checked in)

I checked in this patch on the NSS trunk for NSS 3.12.

Checking in sftkmod.c;
/cvsroot/mozilla/security/nss/lib/softoken/sftkmod.c,v  <--  sftkmod.c
new revision: 1.2; previous revision: 1.1
done
Comment 6 Robert Relyea 2008-01-21 16:03:38 PST
*** Bug 401072 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.