Closed
Bug 107762
Opened 23 years ago
Closed 23 years ago
Fastload leaks spec strings
Categories
(Core :: XPCOM, defect)
Core
XPCOM
Tracking
()
VERIFIED
DUPLICATE
of bug 106860
People
(Reporter: Bienvenu, Assigned: Bienvenu)
Details
(Keywords: memory-leak)
Attachments
(1 file)
3.28 KB,
patch
|
Details | Diff | Splinter Review |
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•23 years ago
|
||
Assignee | ||
Comment 2•23 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.
Updated•23 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Comment 3•23 years ago
|
||
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•23 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.
Comment 5•23 years ago
|
||
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.
Description
•