Closed
Bug 14208
Opened 25 years ago
Closed 25 years ago
[MLK]: Memory leak of 16384 bytes from 1 block allocated in orkinHeap::Alloc(nsIMdbEnv *,DWORD,void * *)
Categories
(MailNews Core :: Database, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M14
People
(Reporter: skasinathan, Assigned: Bienvenu)
References
Details
Overview Description: I found this Memory Leak on my recent Purify runs. I think 16 KB leak is big leak. I have already filed a bug# 10262 for Memory leak in orkinHeap::Alloc. But the stack trace and the number of bytes looks different. Davidmc, I remember you saying "MDB is designed to leak factory and environment objects on purpose". If you think that this bug is related to your comment, please mark this bug as Invalid. Sorry for the inconvenience. Here is the Stack trace. [W] MLK: Memory leak of 16384 bytes from 1 block allocated in orkinHeap::Alloc(nsIMdbEnv *,DWORD,void * *) Distribution of leaked blocks 16384 bytes from 1 block of 16384 bytes (0x08894de8) allocation number 379101 Allocation location new(UINT) [memcmp.asm:23] orkinHeap::Alloc(nsIMdbEnv *,DWORD,void * *) [orkinHeap.cpp:55] { MORK_USED_1(ev); mdb_err outErr = 0; => void* block = new char[ inSize ]; if ( !block ) outErr = morkEnv_kOutOfMemoryError; morkWriter::MakeWriterStream(morkEnv *) [morkWriter.cpp:240] mWriter_Bud = bud; stream = new(*heap, ev) morkStream(ev, morkUsage::kHeap, heap, bud, => morkWriter_kStreamBufSize, frozen); } else bud->CutStrongRef(ev->AsMdbEnv()); morkWriter::WriteMore(morkEnv *) [morkWriter.cpp:328] if ( this->IsWriter() ) { if ( !mWriter_Stream ) => this->MakeWriterStream(ev); if ( mWriter_Stream ) { ??? [ip=0x08853348] morkThumb::DoMore_Commit(morkEnv *) [morkThumb.cpp:464] morkWriter* writer = mThumb_Writer; if ( writer ) { => writer->WriteMore(ev); mThumb_Total = writer->mWriter_TotalCount; mThumb_Current = writer->mWriter_DoneCount; mThumb_Done = ( ev->Bad() || writer->IsWritingDone() ); ??? [ip=0x08853348] morkThumb::DoMore(morkEnv *,DWORD *,DWORD *,BYTE *,BYTE *) [morkThumb.cpp:364] this->DoMore_SessionCommit(ev); break; case morkThumb_kMagic_CompressCommit: // 7 /* store method */ => this->DoMore_CompressCommit(ev); break; case morkThumb_kMagic_SearchManyColumns: // 8 /* table method */ this->DoMore_SearchManyColumns(ev); break; orkinThumb::DoMore(nsIMdbEnv *,DWORD *,DWORD *,BYTE *,BYTE *) [orkinThumb.cpp:225] if ( ev ) { morkThumb* thumb = (morkThumb*) mHandle_Object; => thumb->DoMore(ev, outTotal, outCurrent, outDone, outBroken); outErr = ev->AsErr(); } return outErr; nsMsgFolderCache::Close(void) [nsMsgFolderCache.cpp:426] mdb_bool outBroken = PR_FALSE; // is operation irreparably dead and broken? while (!outDone && !outBroken && ret == NS_OK) { => ret = commitThumb->DoMore(GetEnv(), &outTotal, &outCurrent, &outDone, &outBroken); } if(commitThumb) commitThumb->CutStrongRef(m_mdbEnv);
Assignee | ||
Updated•25 years ago
|
Assignee: bienvenu → davidmc
Assignee | ||
Comment 1•25 years ago
|
||
Wrong David - davidmc does mdb/mork - but you know, I fixed this a while ago, I thought. David, did you crunch my change by accident? It was a ref-counting problem - I can look for the e-mail I sent you.
Yes it looks like I whacked your change as the result of some kind of automerging in CVS, which got part of your fix and part of my fix. I coded a slightly different version of the fix. My file morkThumb.cpp now looks like this: morkThumb::Make_LargeCommit(morkEnv* ev, nsIMdbHeap* ioHeap, morkStore* ioStore) { // ... nsIMdbFile_SlotStrongFile(file, ev, &outThumb->mThumb_File); outThumb->mThumb_Writer = writer; // pass writer ownership to thumb // ... } When it should only have the second assignment: // ... outThumb->mThumb_Writer = writer; // pass writer ownership to thumb // ... I thought this was better the incrementing the refcount in the call to nsIMdbFile_SlotStrongFile(), and then decrementing it immediately.
Assignee | ||
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 3•25 years ago
|
||
this was fixed a while ago.
I could see this leak in my recent purify posting at www.mozilla.org/mailnews/purify. Take a look at '18-November 1999 POP' log and search for 'orkin'. Reopening the bug.
Assignee | ||
Updated•25 years ago
|
Assignee: davidmc → bienvenu
Status: REOPENED → NEW
Assignee | ||
Comment 6•25 years ago
|
||
I'll look at fixing this.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M14
Assignee | ||
Comment 7•25 years ago
|
||
I think the problem here is that the same change needs to be made to compress commit. I'll check in a fix when the tree opens.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•25 years ago
|
||
fixed in morkThumb, as I indicated above.
QA Contact: suresh → stephend
I haven't seen this stack since I've been running Purify.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•