MLK: Memory leak of 1416 bytes from 1 block allocated in orkinHeap::Alloc(nsIMdbEnv *,UINT,void * *) Distribution of leaked blocks 1416 bytes from 1 block of 1416 bytes (0x0ef10d38) Allocation location new(UINT)+0xc [C:\WINNT\SYSTEM32\msvcrt.DLL ip=0x580039cb] orkinHeap::Alloc(nsIMdbEnv *,UINT,void * *)+0x24 [c:\moz_src\mozilla\db\mork\src\orkinHeap.cpp:75 ip=0x0e3063d0] orkinFactory::CreateNewFileStore(nsIMdbEnv *,nsIMdbHeap *,nsIMdbFile *,mdbOpenPolicy const*,nsIMdbStore * *)+0x100 [c:\moz_src\mozilla\db\mork\src\orkinFactory.cpp:772 ip=0x0e302fb1] nsMsgDatabase::OpenMDB(char const*,int)+0x5c8 [c:\moz_src\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp:943 ip=0x0e5dbc56] nsImapMailDatabase::Open(nsIFileSpec *,int,int,nsIMsgDatabase * *)+0x3f8 [c:\moz_src\mozilla\mailnews\db\msgdb\src\nsImapMailDatabase.cpp:99 ip=0x0e5d85dc] nsMsgDatabase::OpenFolderDB(nsIMsgFolder *,int,int,nsIMsgDatabase * *)+0xe7 [c:\moz_src\mozilla\mailnews\db\msgdb\src\nsMsgDatabase.cpp:832 ip=0x0e5db650] nsImapMailFolder::GetDatabase(nsIMsgWindow *)+0x207 [c:\moz_src\mozilla\mailnews\imap\src\nsImapMailFolder.cpp:556 ip=0x08bf1ce6] nsMsgDBFolder::GetMsgDatabase(nsIMsgWindow *,nsIMsgDatabase * *)+0x3f [c:\moz_src\mozilla\mailnews\base\util\nsMsgDBFolder.cpp:625 ip=0x083cb42b] nsMsgFolderDataSource::DoCommand(nsISupportsArray *,nsIRDFResource *,nsISupportsArray *)+0x592 [c:\moz_src\mozilla\mailnews\base\src\nsMsgFolderDataSource.cpp:760 ip=0x082edd59] CompositeDataSourceImpl::DoCommand(nsISupportsArray *,nsIRDFResource *,nsISupportsArray *)+0xd8 [c:\moz_src\mozilla\rdf\base\src\nsCompositeDataSource.cpp:1421 ip=0x0451b348]
*** Bug 96383 has been marked as a duplicate of this bug. ***
16 years ago
Related / Duplicate: bug 35780
changing qa over to myself.
OK, I'm going to add a bunch of patches to this bug that fix a bunch of different mork memory leaks.
Ok, the basic problem was that CloseMdbObject did not clean up the handles the way allowing the ref count to go to 0 did. We use CloseMdbObject to force objects to get closed (even if the ref-count was > 1), but this fix makes it so that if the ref count is 1, CloseMdbObject just does a normal release. I could have put all this code in the code that calls mork, but that would have been 20 or 30 places at least. I've run Purify with this and it doesn't introduce any problems, and does clean up a lot of leaks. I also changed the file code to do something similar. We want to make sure the file gets closed, which is why we call CloseMdbObject, but I put in code to give it a chance to go to a ref-cnt of 0 gracefully.
Comment on attachment 51947 [details] [diff] [review] mork patch to handle CloseMdbObject sr=sspitzer
David Bienvenu - SMOOCH :-)
fix checked in.
On reading one IMAP message with 5 jpeg attachments, I leak the stack that I'll attach. I don't see the stack listed in this bug, however, so I'll just file that as a seperate leak.
Pretty sure that's a seperate stack/leak, so I'll verify this one. Re-open if Mars is my home planet.