Ben Kelly [:bkelly, not reviewing] Assignee
	Description • 8 years ago

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.

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 1 • 8 years ago

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.

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 2 • 8 years ago

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

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 3 • 8 years ago

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.

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 4 • 8 years ago

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.

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 5 • 8 years ago

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

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 6 • 8 years ago

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

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 7 • 8 years ago

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.

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 8 • 8 years ago

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

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 9 • 8 years ago

[Tracking Requested - why for this release]:

	Marcia Knous [:marcia]
	Comment 10 • 8 years ago

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

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 11 • 8 years ago

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

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 12 • 8 years ago

Confirmed.  Backing out bug 1277582 fixes this leak.

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 13 • 8 years ago

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

	Andrew Overholt [:overholt]
	Comment 14 • 8 years ago

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

	Eric Rahm [:erahm]
	Comment 17 • 8 years ago

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

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 18 • 8 years ago

I'll verify tomorrow's nightly build.

	Ben Kelly [:bkelly, not reviewing] Assignee
	Comment 19 • 8 years ago

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.