1084605 - Ghost windows on TechCrunch with the browser console open

Status: REOPENED

(DevTools :: General, defect)

Description

[Andrew McCreight [:mccr8]]

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.

Comment 1

[Andrew McCreight [:mccr8]]

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.

Comment 2

[Andrew McCreight [:mccr8]]

I filed bug 1084626 for the platform side of this, which would be extending NukeCrossCompartmentWrappers to debugger objects.

Comment 3

[Andrew McCreight [:mccr8]]

FWIW, the leak goes away when you close the browser console, which is presumably why we didn't see this on TBPL. ;)

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Why does browser console have anything to do with debugger stuff?

Comment 5

[Andrew McCreight [:mccr8]]

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?

Comment 6

[Jim Blandy :jimb]

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.

Comment 7

[Jim Blandy :jimb]

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.

Comment 8

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(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).

Comment 11

[Julian Descottes [:jdescottes]]

The STRs for the summary no longer reproduce for me, there are 0 ghost windows after following them.

Comment 12

[Andrew McCreight [:mccr8]]

This still reproduces for me, but the steps are slightly different now that we have e10s.

Basically, the extra step is that you have to first open 8 or more tabs with example.com in it. This keeps the processes from getting killed. Also, make sure that Fission is disabled before doing it.

Comment 13

[Andrew McCreight [:mccr8]]

With Fission enabled, the steps to reproduce would again be a little different. You'd have to open TechCrunch in two different tabs instead of one. The leaking window will no longer show up as a ghost window, but you should still be able to see two windows of TechCrunch open in the memory report. (I haven't actually tested this but I think that's how it'll work.)

Comment 14

[Julian Descottes [:jdescottes]]

Indeed, I can reproduce with the new STRs, thanks for the update!