As documented, XPConnect seems to be leaking memory on shutdown. http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/src/nsXPConnect.cpp#104
The comments in nsXPConnect's destructor seems discouraging for me, because I would like to use XPConnect for an ActiveX control / Mozilla NP plugin in a web page. When the control is destroyed, XPCOM is shutdown, and sometimes there is a memory leak. Usually, the memory leak can be generated by some user interaction, which in turn causes JS script to run through our embedded Spidermonkey. XPConnect is used to access C++ XPCOM components through JS. Memory leaks do not seem to occur for our C++ XPCOM objects, when Spidermonkey and XPConnect are not used. Leaking on shutdown may not be much of a problem, in an application that saves shutdown for just prior to terminating the process/application. However, the web control can be instantiated and destroyed repeatedly while browsing several different web pages. I have tried setting the active safe JS context for the thread to be NULL, but XPConnect still seems to be causing a leak. It triggers the infamous "Component Manager being held past XPCOM shutdown." assertion in NS_ShutdownXPCOM. Memory checker tools verify the leak. Note, that I am calling xpConnectService->ReleaseJSContext(context, false) for each context that is created with a call to JS_NewContext. Since most of the objects getting destroyed are our own, is there anything I can do to call "Release on the natives no longer reachable via XPConnect?" If "bad things happen," as warned, then I can try something else. At least, it might give me a place to start debugging the memory leaks. Has anyone got any suggestions about how to prevent memory leaking on destruction of XPConnect? Thanks. _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
