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]
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.
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