We seem to be hanging on to references. Nothing leaks at shutdown. Opening a new browser window and closing the old one does not collect these references.

I just tried that (on a not-quite-tip mac build). I load the page, hold down the reload key. Get about 100 windows. Open a new window. Close the old one. Not much change. Load about:blank in the new window. All the windows get GCed....

does your build have this changeset? Andreas Gal - Enter compartment in AutoScriptEvaluate (bug 630243, r=jst, a=blocker). ?

No. My build is from Jan 28 with some local changes.

Sigh of relief ...

Is this related to the expando leak peterv just fixed?

Doesn't look like it is. There's an event listener held by a div element, we're missing an edge: 0x2046eb98 [nsXPCWrappedJS (nsIDOMEventListener)] 0x20456060 [nsGenericElement (xhtml) div [1/2]] --[[via hash] mListenerManager]-> 0x2046ebd0 [nsEventListenerManager] --[mListeners[i] mListener]-> 0x2046eb98 [nsXPCWrappedJS (nsIDOMEventListener)] known edges: 0x20455fe0 nsGenericElement (xhtml) div --[mAttrsAndChildren[i]]--> 0x20456060

Cc:ing smaug in case the event listener stuff above rings any bells.

Who knows about about:home implementation? It seems to be a mix of that xhtml+js page and some logic in browser.js (And no, a missing edge to XPCWrappedJS DOMEventListener doesn't ring any bells)

Ccing some of the people from the recent about:home changes.

Actually, I'm not sure I can reproduce the problem. Sure, if I press ctrl+r, lots of new DOMWindows are created and kept alive some time. But once GC and CC have both run, extra DOMWindows are deleted. Though, I think I managed to reproduce the problem yesterday :/ Today I'm not getting that "restore session" thing in the page. It is not clear to me when that is shown.

(In reply to comment #10) > Though, I think I managed to reproduce the problem yesterday :/ > Today I'm not getting that "restore session" thing in the page. > It is not clear to me when that is shown. on load of the page browser checks if sessionstore canRestoreSession and flips hidden status of a div.

see BrowserOnAboutPageLoad

Ok, now I know how to get that "Restore previous session" and that doesn't seem to affect the behavior. DOMWindows are collected eventually, at least on my debug linux build. But that missing edge is still strange.

Perhaps page loading should more likely call gc+cc (similarly to what happened before bug 624549). Testing a patch...

This should release DOMWindows earlier. With the patch we end up calling GC more often; morethe way we used to do it. If MaybeCC ends up calling CC, GC+CC is called after page loads and when user becomes inactive. But I still wonder, can anyone actually reproduce possible leak? What if you reload about:home 100 times?

I can reproduce and GC and CC run periodically, we just don't collect because of missing edges.

Looks like the problem is that XPCJSRuntime::SuspectWrappedNative calls GetFlatJSObjectAndMark instead of GetFlatJSObjectNoMark :-/. I'll verify in the morning.

So even with the change to XPCJSRuntime::SuspectWrappedNative (which will be done as part of bug 614347) we keep windows alive. It looks like we do need changes to GC scheduling. I've been able to reload about:home 50 times without any GC happening. We do run a bunch of CC's, but those aren't able to collect anything because anything held by the JS objects is not collectable. I think the current GC scheduling is having a really bad effect on the effectiveness of the CC.

Peter, could you try attachment 509451 [details] [diff] [review]?

Reloading would be a perfect time for GC but it might slow town page transitions :(

We have had GC+CC after page load for ages. Bug 624549 made those less likely, and attachment 509451 [details] [diff] [review] makes them again more likely.

From a quick test it looks like attachment 509451 [details] [diff] [review] helps here. Smaug, want to take the bug?

For the record the marking problem (comment 17) will be fixed with bug 614347.

sayrer, can you turn this into a testcase? we should not have such massive leaks and none of our tests tell us

http://hg.mozilla.org/mozilla-central/rev/0a2e06927c31 but keeping this still open because of comment 18 (about bug 614347)

I'm not sure if this is related, but load about:memory and hold F5 Easy to monitor some mem numbers, steady grow until GC, then grow bit more again, goto GC PS. Mozilla/5.0 (X11; Linux i686; rv:2.0b12pre) Gecko/20110209 Firefox/4.0b12pre

cdleary-bot mozilla-central merge info: http://hg.mozilla.org/mozilla-central/rev/d07aab3b3b7c Note: not marking as fixed because fixed-in-tracemonkey is not present on the whiteboard.

I think we can mark this a dup of 630932 now. That bug will take care of GC and CC scheduling. That bug should land shortly. Please re-open if you disagree.