Seeing this on Solaris 2.6, current build from May 26, 1999. MLK: 15 bytes leaked at 0x14009e0 * This memory was allocated from: malloc [rtlib.o] __bUiLtIn_nEw [libgcc.a] __builtin_new [rtlib.o] __bUiLtIn_vEc_nEw [libgcc.a] __builtin_vec_new [rtlib.o] nsString::ToNewCString()const [nsString.cpp:667] nsScriptNameSpaceManager::RegisterGlobalName(const nsString&,const nsID&,int) [nsScriptNameSpaceManager.cpp:69] nsAppCoresNameSet::AddNameSet(nsIScriptContext*) [nsAppCoresNameSet.cpp:160] nsScriptNameSetRegistry::PopulateNameSpace(nsIScriptContext*) [nsScriptNameSetRegistry.cpp:98] nsJSContext::GetNameSpaceManager(nsIScriptNameSpaceManager**) [nsJSEnvironment.cpp:347] nsJSUtils::nsGlobalResolve(JSContext*,JSObject*,long) [nsJSUtils.cpp:387] ResolveWindow(JSContext*,JSObject*,long) [nsJSWindow.cpp:779] _js_LookupProperty [jsobj.c:1503] LookupProperty [jsapi.c:1341] JS_LookupProperty [jsapi.c:1494] NS_InitXULTreeElementClass [nsJSXULTreeElement.cpp:221] NS_NewScriptXULTreeElement [nsJSXULTreeElement.cpp:282] RDFElementImpl::GetScriptObject(nsIScriptContext*,void**) [nsRDFElement.cpp:1212] nsEventListenerManager::AddScriptEventListener(nsIScriptContext*,nsIScriptObject Owner*,nsIAtom*,const nsString&,const nsID&) [nsEventListenerManager.cpp:409] RDFElementImpl::AddScriptEventListener(nsIAtom*,const nsString&,const nsID&) [nsRDFElement.cpp:1933] RDFElementImpl::SetAttribute(int,nsIAtom*,const nsString&,int) [nsRDFElement.cpp:1832] RDFXULBuilderImpl::AddAttribute(nsIContent*,nsIRDFResource*,nsIRDFNode*) [nsRDFXULBuilder.cpp:2254] RDFXULBuilderImpl::CreateXULElement(nsINameSpace*,nsIRDFResource*,int,nsIAtom*,n sIContent**) [nsRDFXULBuilder.cpp:2038] RDFXULBuilderImpl::CreateElement(nsINameSpace*,nsIRDFResource*,nsIContent**) [nsRDFXULBuilder.cpp:1690] RDFXULBuilderImpl::AppendChild(nsINameSpace*,nsIContent*,nsIRDFNode*) [nsRDFXULBuilder.cpp:1525] RDFXULBuilderImpl::CreateContents(nsIContent*) [nsRDFXULBuilder.cpp:634] XULDocumentImpl::CreateContents(nsIContent*) [nsXULDocument.cpp:2562] RDFElementImpl::EnsureContentsGenerated()const [nsRDFElement.cpp:2461] RDFElementImpl::ChildCount(int&)const [nsRDFElement.cpp:1460] nsCSSFrameConstructor::ProcessChildren(nsIPresContext*,nsFrameConstructorState&, nsIContent*,nsIFrame*,int,nsFrameItems&) [nsCSSFrameConstructor.cpp:667]

Hmm...that block of memory should be deallocated in nsScriptNameSpaceManager::RemoveNames(). I did a bit more investigation and found missing NS_RELEASE() calls in the following methods: nsMessengerNameSet::AddNameSet (http://lxr.mozilla.org/seamonkey/source/mailnews/base/src/nsMessengerNameSet.cp p#60) nsComposerNameSet::AddNameSet (http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsComposerNameSet. cpp#74) In both cases, the nsIScriptNameSpaceManager reference should be released. Passing the bug on to alecf, since there is a comment (I believe erroneous) that the manager shouldn't be released.

I cut and pasted that comment from some other code. I'll try NS_RELEASEing it and see what happens.

This code is going away completely thanks to XPConnect. I will probably have killed our appcore today, so I won't need a namespace manager.

Ok, this has been fixed by XPConnecting the messenger appcore. reassigning to jfd so that he can mark this fixed when he XPConnects the compose appcore

nsComposerNameSet.cpp doesn't exist anymore as I have totally removed the composeAppcore.

Jean-Francois, or bruce [Reporter], Could you please verify this bug, or provide a testcase and steps how to verify it.

nsComposerNameSet.cpp still in the tree but it will be removed as soon the tree open for M8. nsComposerNameSet.cpp isn't part of the build anymore.

Jean-Francois, So should I mark it verified ?

YES

Marking verified.