I have a 3 leaked windows this morning in my dmd nightly instance: ├────7.45 MB (01.55%) -- window-objects │ ├──7.06 MB (01.47%) -- top(none) │ │ ├──7.06 MB (01.47%) -- ghost │ │ │ ├──5.44 MB (01.13%) ++ window(https://irccloud.mozilla.com/#!/ircs://irc1.dmz.scl3.mozilla.com:6697/%23content) │ │ │ └──1.63 MB (00.34%) -- (2 tiny) │ │ │ ├──1.53 MB (00.32%) ++ window(https://dxr.mozilla.org/mozilla-central/source/) │ │ │ └──0.10 MB (00.02%) ++ window(about:blank) │ │ └──0.00 MB (00.00%) ── detached/window(https://irccloud.mozilla.com/#!/ircs://irc1.dmz.scl3.mozilla.com:6697/%23content)/dom/other I traced the all 3 windows. They all showed a reference held through an "ipc-object": $ grep nsGlobalWindow * | grep dxr cc-edges.9976.1484666452.log:0000027202826800 [rc=12] nsGlobalWindow # 4294969588 inner https://dxr. mozilla.org/mozilla-central/source/ bkelly@kosh /c/devel/tmp/cclogs/irccloud $ /c/devel/heapgraph/find_roots.py cc-edges.9976.1484666452.log 0000027202826800 Parsing cc-edges.9976.1484666452.log. Done loading graph. 00000275090C8240 [JS Object (Window)] --[UnwrapDOMObject(obj)]--> 0000027202826800 [nsGlobalWindow # 4294969588 inner https://dxr.mozi lla.org/mozilla-central/source/] Root 00000275090C8240 is a marked GC object. bkelly@kosh /c/devel/tmp/cclogs/irccloud $ /c/devel/heapgraph/find_roots.py gc-edges.9976.1484666452.log -bro 00000275090C8240 Parsing gc-edges.9976.1484666452.log. Done loading graph. via ipc-object : 000002750D8582A0 [Proxy <no private>] --[group]--> 0000027255E365B0 [object_group] --[group_global]--> 00000275090C8240 [Window <no private>] I'm not sure what an "ipc-object" in terms of the trace means, though. Unfortunately I don't have steps to reproduce.

(In reply to Ben Kelly [:bkelly] from comment #0) > I'm not sure what an "ipc-object" in terms of the trace means, though. It's probably a CPOW. This can be another side effect of Bug 1311212, if so, Andrew is working on something related under bug 1330018.

Yeah, ipc-object means a CPOW. You can just search for ipc-object in SearchFox and you'll get pointed at the trace method for CPOWs.

Note, I did not have multiple content processes enabled.

Yeah, I have no idea why that other bug only shows up with e10s-multi. It can happen any time a CPOW gets sent to the parent, and the parent fails to process the message.

Let me know if you see this again once the fix has gotten onto whatever branch you are using. Are you using either Nightly or Aurora? If you are not using either then maybe there is something else going on here.

Oh never mind, you said Nightly in comment 0. Thanks for the bug report. It was good to know this can happen in the real world, even without e10s-multi.

I was on nightly, but have been running the release candidate last couple days. I'll switch back to nightly tomorrow after updates are turned back on there. Thanks!