33338 - MLK: Mork memory leaks, need help understanding.

Status: VERIFIED DUPLICATE of bug 35913

(MailNews Core :: Database, defect, P3)

Description

[Bruce Mitchener]

I was looking into this memory leak (as reported by beard's tools):

malloc
operator new(unsigned long, const std::nothrow_t&)
operator new(unsigned long)
orkinHeap::Alloc(nsIMdbEnv*, unsigned long, void**)
morkNode::MakeNew(unsigned long, nsIMdbHeap&, morkEnv*)
morkTable::NewTableRowCursor(morkEnv*, long)
orkinTable::GetTableRowCursor(nsIMdbEnv*, long, nsIMdbTableRowCursor**)
nsMsgDBEnumerator::GetRowCursor()
nsMsgDBEnumerator::PrefetchNext()
nsMsgDBEnumerator::HasMoreElements(int*)
nsMessageFromMsgHdrEnumerator::HasMoreElements(int*)
nsMessageViewMessageEnumerator::HasMoreElements(int*)
CompositeEnumeratorImpl::HasMoreElements(int*)
RDFGenericBuilderImpl::CreateContainerContents(nsIContent*, nsIRDFResource*,
int, nsIContent**, int*)
RDFGenericBuilderImpl::CreateTemplateAndContainerContents(nsIContent*,
nsIContent**, int*)
RDFGenericBuilderImpl::RebuildContainer(nsIContent*)
nsXULDocument::RebuildWidgetItem(nsIContent*)
nsXULDocument::AttributeChanged(nsIContent*, int, nsIAtom*, int)
nsXULElement::SetAttribute(int, nsIAtom*, const nsString&, int)
nsXULElement::SetAttribute(const nsString&, const nsString&)
nsXULTreeElement::SetAttribute(const nsString&, const nsString&)
ElementSetAttribute(JSContext*, JSObject*, unsigned int, long*, long*)
js_Invoke
js_Interpret
js_Invoke
nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, const
nsXPTMethodInfo*, nsXPTCMiniVariant*)
nsXPCWrappedJS::CallMethod(unsigned short, const nsXPTMethodInfo*,
nsXPTCMiniVariant*)
PrepareAndDispatch
nsInterfaceInfo::AddRef()(1D7DE630)
nsMsgMailSession::NotifyFolderLoaded(nsIFolder*)

And I got to looking at nsMsgDBEnumerator and noticed its destructor:

nsMsgDBEnumerator::~nsMsgDBEnumerator()
{
   if (mRowCursor)
          mRowCursor->CutStrongRef(mDB->GetEnv());
   NS_RELEASE(mDB);
   NS_IF_RELEASE(mResultHdr);
}

Now, I don't know how Mork's memory management works, but I'm not seeing where
the actual memory allocated for mRowCursor gets freed.  Can anyone help?

I know that Mork was designed to leak some  amount of memory with the
environments, but right now, we're leaking a lot more than some minimal amount
of memory and I don't see where this particular leak is related to environments.

Comment 1

[David :Bienvenu]

cutstrongref is like a release - it's a ref-counted object, and cutting the last 
reference should make the count go to 0 and the object get deleted.

Comment 2

[Bruce Mitchener]

Okay. I followed through the code and I understand this now.  How do Mork-based 
memory leaks get tracked down?  There aren't any hooks into the refcnt debugging 
utilities that the rest of the codebase uses.

Comment 3

[David :Bienvenu]

generally, I have to do it. It usually turns out to be a leak above Mork (e.g., 
in this case, is nsMsgDBEnumerator getting leaked?)

Comment 4

[Bruce Mitchener]

I think that is what is getting leaked.  Do you have Purify or a Mac where you 
can run beard's boehm GC stuff?  There's a good bit of stuff leaking related to 
Mork (but probably isn't Mork itself) that isn't composed of the Mork 
environment stuff that is expected to leak.

Comment 5

[David :Bienvenu]

sure, I have Purify, but I'm supposed to be only working on features at the
moment, unfortunately. When I can go back to fixing bugs, I can look at this.
However, if it's the nsMsgDBEnumerator that's leaking, it's not  likely that
it's my code.

Comment 6

[Bruce Mitchener]

Understood ... After a few other leaks get fixed, maybe I'll have the chance to 
look into these and the others that I have to report more to save you the 
effort.  No promises though.

Comment 7

[David :Bienvenu]

thanks, Bruce, you rock!

Comment 8

[davidmc]

Any object returned from the MDB interface from Mork is actually a fixed sized 
handle wrapper for a real underlying object.  I think all these handles are 
allocated by the environment object and go on free lists.  So when envs are 
leaked and also not closed, then we would expect to see any handles allocated 
from the env's pool to also be leaked.  But when we are done with the env we 
could close it to free any memory referenced by the env.

Note the purpose of strong refs in mork is to cooperatively close objects when 
uses hit zero.  This is distinct from weak refs (which must always be equal or 
greater than strong refs) which merely control memory allocation lifetime.

Any object beginning with prefix 'mork' is a 'real' object representing a more 
serious memory leak.  All 'orkin' objects are merely handle wrappers that go on 
free lists, and are less serious since they are connected to env lifetime.

Comment 9

[Bruce Mitchener]

Great.  Thanks for this information.  Is this documented anywhere or should I 
create a tome of memory management hints for Mozilla and document this in that?

Comment 10

[davidmc]

I might have said some of this in the mail/news newsgroup, in postings still 
readbable with infinite expiry on the mozilla nntp server.  But I said too much 
about Mork for most folks to read in order to find essential bits.  (Assume I 
said four times as much as you are actually willing to read. :-)

It would have been a good idea to recapture all the Mork design stuff as web 
pages, so folks could navigate to parts directly relevant to some problem.  I 
should have undertaken an initiative to do this myself, since Netscape is a bit 
shy about writing docs, so it appears nowhere in our development process.  But 
now it's too late to do so, since my last day is planned for Friday 07April2000.

However, I guess I'm happy to answer ongoing questions.  I know this is not the 
same as writing a sumptuous set of clear design docs.

In the coming months after I finish my Mithril scripting language, I vaguely plan 
to write a pluggable Mork replacement in Mithril which uses the same MDB 
interface and Mork text format, but which creates a standalone server so it would 
be possible to shared access to address books and history db, etc.  I would do 
this only for sample app purposes to illustrate basic Mithril concepts, and 
because it would be trivially easy to do, and would thus eat little of my time

Comment 11

[selmer (gone)]

Target M17.

Comment 12

[scottputterman]

moving to future.

Comment 13

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

bienvenu:  Is this the same as bug 35913?  (Note:  that fix didn't fix all the 
mork leaks I was seeing.  More info coming...)

Comment 14

[David :Bienvenu]

ah, yes it is the same. I wouldn't expect that fix to fix all mork memory leaks;
just the ones with GetTableRowCursor on the stack.

*** This bug has been marked as a duplicate of 35913 ***

Comment 15

[lchiang]

verified dup