1286008 - leaked non-detached twitter windows

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 6

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

(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?

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 9

[Ben Kelly [:bkelly, not reviewing]]

[Tracking Requested - why for this release]:

Comment 10

[Marcia Knous [:marcia]]

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

Comment 11

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 12

[Ben Kelly [:bkelly, not reviewing]]

Confirmed.  Backing out bug 1277582 fixes this leak.

Comment 13

[Ben Kelly [:bkelly, not reviewing]]

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

Comment 14

[Andrew Overholt [:overholt]]

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

Comment 17

[Eric Rahm [:erahm]]

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

Comment 18

[Ben Kelly [:bkelly, not reviewing]]

I'll verify tomorrow's nightly build.

Comment 19

[Ben Kelly [:bkelly, not reviewing]]

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.