Fastload leaks spec strings

VERIFIED DUPLICATE of bug 106860

Status

()

Core
XPCOM
VERIFIED DUPLICATE of bug 106860
16 years ago
16 years ago

People

(Reporter: Bienvenu, Assigned: Bienvenu)

Tracking

({mlk})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

16 years ago
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]
(Assignee)

Comment 1

16 years ago
Created attachment 55917 [details] [diff] [review]
proposed fix
(Assignee)

Comment 2

16 years ago
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

Updated

16 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 16 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 ***
(Assignee)

Comment 4

16 years ago
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.