96379 - MLK: Memory leak of 1416 bytes from 1 block allocated in orkinHeap::Alloc(nsIMdbEnv *,UINT,void * *)

Status: VERIFIED FIXED

(MailNews Core :: Database, defect)

Description

[[e-mail] (gone - use [e-mail] instead)]

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]

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 96383 has been marked as a duplicate of this bug. ***

Comment 2

[Håkan Waara]

Related / Duplicate: bug 35780

Comment 3

[[e-mail] (gone - use [e-mail] instead)]

changing qa over to myself.

Comment 4

[David :Bienvenu]

OK, I'm going to add a bunch of patches to this bug that fix a bunch of
different mork memory leaks.

Comment 5

[David :Bienvenu]

Attachment: mork patch to handle CloseMdbObject

Comment 6

[David :Bienvenu]

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 7

[(not reading, please use [e-mail] instead)]

Comment on attachment 51947 [details] [diff] [review]
mork patch to handle CloseMdbObject

sr=sspitzer

Comment 8

[[e-mail] (gone - use [e-mail] instead)]

David Bienvenu - SMOOCH :-)

Comment 9

[Navin Gupta]

r=naving

Comment 10

[David :Bienvenu]

fix checked in.

Comment 11

[[e-mail] (gone - use [e-mail] instead)]

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.

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

Attachment: Stack

Comment 13

[[e-mail] (gone - use [e-mail] instead)]

Pretty sure that's a seperate stack/leak, so I'll verify this one.  Re-open if 
Mars is my home planet.