1. open the browser console 2. go to http://techcrunch.com/ 3. close the tab for tech crunch 4. go to about memory, hit minimize memory usage, then measure memory TechCrunch is now a ghost window. I'm not sure what is going on here. It looks like there's a path entirely through JS from chrome to content, which shouldn't happen with the huey fix. This may be a platform bug, but I'm filing in devtools for now.
Jim, it looks like there's a debugger object that has a weak map, where there is a weak map entry that looks like this: 0x11698c1f0 B Object 1169d2380 > 0x121e92e78 B type > 0x121ea1358 B shape > 0x1169d2380 B Debugger.Object referent > 0x12603c100 B **UNKNOWN SLOT 0** The Debugger.Object referent is what looks like a window global for http://techcrunch.com/wp-content/themes/vip/techcrunch-2013/_uac/adpage.html which I guess is some ad thing. I see no JS proxy, which is how this leak is evading the huey fix. Do you have some idea what is going on here? I assume these chrome-content edges are mentioned to the GC, somehow. In addition to making dev tools not hold onto this stuff, it would be nice if we could somehow nuke debugger references to content at the same time we do that for regular cross compartment wrappers.
I filed bug 1084626 for the platform side of this, which would be extending NukeCrossCompartmentWrappers to debugger objects.
FWIW, the leak goes away when you close the browser console, which is presumably why we didn't see this on TBPL. ;)
Why does browser console have anything to do with debugger stuff?
I have no idea. I also couldn't reproduce on every site. Maybe the console keeps some kind of handle to the window when the window triggers an error?
I'm not familiar with the browser console, so I can't say why there's a Debugger.Object involved, but the web console uses Debugger.Object.prototype.evalInGlobalWithBindings and Debugger.Frame.prototype.evalWithBindings to evaluate expressions. But I think Debugger is a red herring here. If that WeakMap entry is being held alive, then whoever is holding the WeakMap or the key alive is at fault. Debugger.Objects always strongly hold their referents; someone's using a WeakMap to hold on to a D.O, so that part of the system is functioning as designed.
Shu pointed out that my comment 6 might be misunderstood. I would be perfectly happy for NukeCrossCompartmentWrappers to sever D.O -> referent connections, just as it does for CCWs. There's no reason a D.O should have special protection from a NukeCCWs call. My intent in comment 6 was simply to say that the references shown in comment 1 don't reflect a bug in Debugger, but rather a bug in whatever code is *using* Debugger. But NukeCCWs doesn't care whose fault it is; it just wants to cut all the connections. So it seems fine to sever D.Os, too, as long as attempts to use a severed D.O throw appropriate exceptions.
(In reply to Jim Blandy :jimb from comment #6) > I'm not familiar with the browser console, so I can't say why there's a > Debugger.Object involved, but the web console uses > Debugger.Object.prototype.evalInGlobalWithBindings and > Debugger.Frame.prototype.evalWithBindings to evaluate expressions. The browser console is just the webconsole but debugging all globals in the runtime. It additionally uses Debugger.Object to display/inspect debuggee objects (both in the inline REPL and the sidebar when clicking on one of those for more details).
You need to log in before you can comment on or make changes to this bug.