The following objects leak when running the bloat tests (setenv XPCOM_MEM_LEAK_LOG 1; ./mozilla -P <prof-name> -f bloaturls.txt): class obj ref ----- --- --- nsXPCComponents 2 6 nsXPCComponents_Classes 1 3 nsXPCComponents_Interfaces 1 1 nsXPCComponents_Results 1 1 nsXPCWrappedNative 20 20 nsXPCWrappedNativeClass 5 20 nsXPCWrappedNativeScope 2 20 These leaks do not seem related to the leak of the GlobalWindowImpl, as I pointed out in my comment on bug 33673 at 2000-05-15 16:18. It appears that many of the nsXPCWrappedNative are not being garbage collected. They seem to be addrefed (in their constructor) so that they will be garbage-collected later. I took refcount balancer logs on all the XPCWrappedNative objects leaked, and only one of them (#8 in the logs at the URL below) was garbage collected, but I think it was leaked because it was owned by another leaked XPCWrappedNative. Some other leaks appear to be related to / caused by these leaks: CIDGetService, RDFServiceImpl (maybe), nsStringBundleService, which in turn probably leak other things. I have a good bit of refcount balancer output at: http://dbaron.student.harvard.edu/u/david/leaks/aboutblank/ Files ending in balance-ib are --ignore-balance output, and ending in balance-ic are output with nsCOMPtrs negated, etc... That output will only be there until Wednesday or so. After that, if you want me to send it to you, I can...

mccabe - It looks (from tinderbox) like you just fixed this. Was it intentional? :-)

It's news to me! If you end up finding out what fixed this, I'd love to know.

Hm. One possibility if it does turn out to be me: I just checked in a change that makes XPConnect use a DOM-special JSContext when on the DOM thread, as the fallback context to use when it can't find a more appropriate one. This fallback ends up being used for JS Components. Perhaps some JS component was holding on to a Components object? Or the generic context that used to be used wasn't being destroyed, and it was holding on to a JS Components' global, which has a Components?

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

I'm leaving this open because this bug may still exist, and just be dependent on things happening in a certain order. The bug I just marked as a duplicate of this bug was a previous occurrence of these XPConnect related leaks, I think, and was probably triggered and resolved by two unrelated changes. However, it could be that this really is fixed for good...

CCing shaver.

I can reproduce this on (at least) Linux by moving one of the scroll bars. To reproduce just go to http://www.mozilla.org and scroll up and down.

also, we don't leak the above classes if I do the exact same test on 'viewer'. Is this a 'chrome' thing?

This just keeps getting better. If I open mozilla to www.mozilla.org, scroll up and down (using the grippy or up/down keys but not the up/down buttons), and then exit using the 'quit' menu item then I also get a webshell leak. Doing the above results in bloatview indicating a 1.1M total leak.

I may be deluded... but I don't believe that xpconnect has any intrinsic leaks of any importance at this point. Each JSContext has a JS global object with a "Components" object as a property. There are xpconnect objects involved in making that work. Any JSContexts alive at shutdown time will cause these leaks. The xpconnect 'safe context per thread" scheme relies on nspr callbacks to clean itself up upon thread exit. Threads alive at shutdown do not recieve such callbacks. So their associated JSContext's may not be cleaned up. Oh well. By replacing the main thread safe context with one created (and destroyed!) by the DOM we've removed a set of shutdown leaks. Fine. There are are plenty of application specific activities that will cause the DOM system to leave behind *lots* of JSContexts. When that happens xpconnect objects will leak. They will also leak when they are rooted by xpcom references from outside of xpconnect and when plain JS objects still retain references to any xpconnect wrappers when the final JS gc call happens prior to xpcom shutdown. These issues are outside of the scope and control of xpconnect. Someone reopen this if you see a real problem remaining.

I think this leak still happens some of the time (but just not on the bloat tests anymore), but I'd have to double-check (so I'm waiting to reopen). It may not be XPConnect's fault, but even if it isn't we might need your help debugging/understanding it...