I hit a new kind of leak today (for me anyway). I closed all my twitter tabs and windows, but about:memory still showed: ├──158.60 MB (39.12%) -- window-objects │ ├──117.16 MB (28.90%) ++ top(https://twitter.com/, id=2147483670) │ ├───41.11 MB (10.14%) ++ top(https://twitter.com/helloanselm, id=2147483962) This is after closing everything except an example.com content tab and the about:memory tab. The outer windows here both have 4 unknown edges: 000001CE8C569400 [nsGlobalWindow # 2147483962 outer https://twitter.com/helloanselm] Root 000001CE8C569400 is a ref counted object with 4 unknown edge(s). known edges: 000001CE92511840 [nsJSContext] --[mGlobalObjectRef]--> 000001CE8C569400 000001CE8DC5F400 [nsGlobalWindow # 2147483964 inner https://twitter.com/helloanselm] --[mOute rWindow]--> 000001CE8C569400 000001CE905F0500 [nsWindowRoot] --[mWindow]--> 000001CE8C569400 And: 000001CED0B8D000 [nsGlobalWindow # 2147483670 outer https://twitter.com/] Root 000001CED0B8D000 is a ref counted object with 4 unknown edge(s). known edges: 000001CE96549470 [Event] --[mView]--> 000001CED0B8D000 000001CE844EE3E0 [Event] --[mView]--> 000001CED0B8D000 000001CEE132F800 [nsGlobalWindow # 2147483697 inner https://twitter.com/] --[mOuterWindow]--> 000001CED0B8D000 000001CED0B69600 [nsWindowRoot] --[mWindow]--> 000001CED0B8D000 000001CE9702B500 [Event] --[mView]--> 000001CED0B8D000 000001CED0D504C0 [nsJSContext] --[mGlobalObjectRef]--> 000001CED0B8D000 000001CED1E28590 [Event] --[mView]--> 000001CED0B8D000 000001CE96D4C430 [Event] --[mView]--> 000001CED0B8D000 Unfortunately I was not running a build with symbols so I could not set a breakpoint in nsGlobalWindow::Release(). This is in 50.0a1 (2016-07-11) on win10.

This also has this leak: 00000263A74D57E0 [BackstagePass 263a5017340] --[AutoCompleteE10S]--> 00000263A5245F80 [Object <no private>] --[_popupCache]--> 00000263A79D0B40 [Object <no private>] --[browserWindow]--> 00000263A588DC60 [Proxy <no private>] --[private]--> 00000263A21F1040 [Proxy <no private>] --[private]--> 00000263A21E0060 [Window <no private>] Which is bug 1283262. Not sure if its is the root cause here, though.

This is trivial to reproduce. STR: 1) Open a fresh nightly browser 2) Open example.com in a new tab 3) Open twitter.com in a new tab (logged in) 4) Open about:memory in a new tab 5) Minimize and measure memory 6) Note the twitter and example.com windows in the content process 7) Close the twitter tab 8) Minimize and measure memory 9) Note that the twitter tab is still listed in the content process

In a debug build I got slightly different behavior. The outer window does not leak and running the verbose CC logs cleans up the twitter.com inner window. So this seems to depend on bug 1283264 somehow.

I was able to get the outer window to leak in a DEBUG build. Unfortunately placing a breakpoint in Release() did not really help. Whatever is holding the window alive doesn't seem to Release() on shutdown.

It would be really helpful if someone could bisect this. Unfortunately I don't have the time to do it today.

(In reply to Ben Kelly [:bkelly] from comment #4) > I was able to get the outer window to leak in a DEBUG build. Unfortunately > placing a breakpoint in Release() did not really help. Whatever is holding > the window alive doesn't seem to Release() on shutdown. I assume you didn't have XPCOM_MEM_LEAK_LOG set and didn't get leak log?

I just tried XPCOM_MEM_LEAK_LOG, but I couldn't even get a simple example.com tab to load with that enabled. Not sure what is wrong with my config.

Ok, I was able to run with XPCOM_MEM_LEAK_LOG, but I don't get any output from it. I hit this first: Hit MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.) at c:/devel/mozilla-central/tool kit/components/terminator/nsTerminator.cpp:158

[Tracking Requested - why for this release]:

Tracking 50+ since this a popular site and we should see what we can do to address this leak.

I bisected with mozregression and it suggests its this commit: 2016-07-12T09:58:29: DEBUG : Found commit message: Bug 1277582 - Don't send SendPHttpChannelConstructor ipdl messages during child shutdown r=dragana,jdm MozReview-Commit-ID: F6pCCn4jPVb

Confirmed. Backing out bug 1277582 fixes this leak.

Alternatively we can fix this leak by fixing our error handling in the service worker paths in bug 1286258.

(Ben's working on this in a related bug)

Ben did your patch from bug 1286258 end up fixing this?

I'll verify tomorrow's nightly build.

I verified this is fixed in the current nightly build. I'm not marking this a duplicate since its really an interaction from both bug 1277582 and bug 1286258. We fixed the overall problem in bug 1286258 and uplifted it to beta/aurora, but this leak was never present in those branches.