Closed Bug 107762 Opened 23 years ago Closed 23 years ago

Fastload leaks spec strings

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 106860

People

(Reporter: Bienvenu, Assigned: Bienvenu)

Details

(Keywords: memory-leak)

Attachments

(1 file)

Here's a sample stack trace. It's not an accurate one because we're purifying
release builds, but the problem is that a couple hash tables aren't freing the
data allocated in the entries. Patch upcoming.

    malloc         [msvcrt.DLL]
    nsMemoryImpl::Alloc(UINT) [nsMemoryImpl.obj:320]
    nsMemory::Clone(void const*,UINT) [nsMemoryImpl.cpp:592]
    nsFastLoadFileUpdater::Open(nsFastLoadFileReader *) [nsFastLoadFile.cpp:2293]
                // release the reference.
                NS_IF_ADDREF(obj);
                writeEntry->mObject = NS_REINTERPRET_CAST(nsISupports*, key);
     =>         writeEntry->mOID = oid;
                writeEntry->mInfo = *NS_STATIC_CAST(nsFastLoadSharpObjectInfo*,
                                                    readEntry);
            }
    NS_NewFastLoadFileUpdater(nsIObjectOutputStream * *,nsIOutputStream
*,nsIObjectInputStream *) [nsFastLoadFile.cpp:2339]
Attached patch proposed fixSplinter Review
Fix is to enumerate the hash tables freeing the strings - I'm not sure if the
null check is needed - does nsMemory check for null? I don't see the leaks in
purify after this change. Anyway, requesting reviews.
Status: NEW → ASSIGNED
Keywords: mlk
QA Contact: scc → stephend
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
No enumeration should be necessary, because the table clears entries when it is
Finished or Destroyed, and Finish calls clearEntry.  See strmap_ClearEntry in
nsFastLoadFile.cpp.

I think this is a dup of bug 106860, which cites the same purify-reported leaks.
 I believe we must be leaking the entire XPCOM object (nsFastLoadFileWriter or
nsFastLoadFileUpdater) to cause these string leaks.  Enumerating to free the
mStrings just papers over this larger leak.

/be

*** This bug has been marked as a duplicate of 106860 ***
yes, I think you're right - I just discovered that under Purify - don't know why
it didn't show up the second time I ran Purify. 
Anyone have XPCOM_MEM_LEAK_LOG output showing an nsFastLoadFile* leak?

/be
verified dup.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: