Closed Bug 1177727 Opened 9 years ago Closed 9 years ago

Ghost windows on Gmail and


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

Not set



Tracking Status
firefox41 --- fixed


(Reporter: mccr8, Assigned: baku)


(Blocks 1 open bug)


(Keywords: memory-leak, regression, Whiteboard: [MemShrink:P1])


(1 file, 1 obsolete file)

I have a bunch of ghost windows from Google plus.

Here's the start of the path entraining one of the nsGlobalWindows:

0x136659480 [DOMEventTargetHelper]
    --[mListenerManager]--> 0x1392b2310 [EventListenerManager]
    --[mListeners event=onmessage listenerType=1 [i]]--> 0x13abdc970 [JSEventHandler handlerName=onmessage]
    --[mTypedHandler.Ptr()]--> 0x13abdc940 [CallbackObject]
    --[mCallback]--> 0x1616a5700 [JS Object (Function - Mda/b.port1.onmessage)]
    --[group_function, function]--> 0x164a96ec0 [JS Object (Function - Mda/b.port1.onmessage)]

    Root 0x136659480 is a ref counted object with 1 unknown edge(s).
    known edges:
       0x135f63580 [MessageChannel] --[mPort1]--> 0x136659480

I'll see if I can figure out how to reproduce it. You have to look for window/detached because until you close gmail it won't be treated as a ghost window.
Assignee: nobody → continuation
Keywords: mlk
Whiteboard: [MemShrink]
Just curious, is this e10s or non-e10s?

Though, that probably doesn't matter.
baku, could you take a look at this?

What happens to MessagePorts between windowA and windowB when windowA is closed?
Flags: needinfo?(amarchesini)
When WindowA is closed, MessagePort receives a inner-window-destroyed notification and it calls Close().
At this point we send a PBackground message to close the other side and we release the MessagePort.
When the port hosted in windowB receives the Close(), we release that port.
Similar story if we have a worker. And we have some mochitest for this.

Would be nice if we can reproduce it somehow. Maybe we can debug it together today.
Flags: needinfo?(amarchesini)
I found a way to consistently reproduce something that looks like this:
1. Go to, scroll down to the bottom so it all starts loading up, then up to the top.
2. Click on a news story, scroll down to the bottom then back up to the top.
3. While it is still loading, close the tab.

This causes both and the news story pages to be leaked.
Now that there is STR maybe baku could investigate. :)
Assignee: continuation → nobody
Flags: needinfo?(amarchesini)
I can reproduce this both with and without e10s.

[Tracking Requested - why for this release]: severe memory leaks
Summary: Ghost windows on → Ghost windows on Gmail and
Blocks: 952139
Keywords: regression
Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)
Attached patch mp2.patch (obsolete) — Splinter Review
The issue is that, when 1 MessageChannel is created, 2 MessagePorts are created too and they know each other to optimize postMessages in the same window.
They both are observers for inner-window-destroy.
When the window is closed, the first port receives the notification and it close itself and the other port. At this point we forget to call RemoveObserver.

This patch does:
1. RemoveObserver is called before call the manual Release(). Note: MessagePort needs to do this because we don't have multi-thread CC.
2. ::Observe() must be received only when the MessagePort is keeping itself alive.
Attachment #8626922 - Flags: review?(continuation)
Attached patch mp2.patchSplinter Review
Attachment #8626922 - Attachment is obsolete: true
Attachment #8626922 - Flags: review?(continuation)
Attachment #8626924 - Flags: review?(continuation)
Comment on attachment 8626924 [details] [diff] [review]

Review of attachment 8626924 [details] [diff] [review]:

Sounds reasonable to me. Thanks for the quick fix.
Attachment #8626924 - Flags: review?(continuation) → review+
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
I'm going to retroactively mark this as a MemShrink P1.
Whiteboard: [MemShrink] → [MemShrink:P1]
Adding a tracking flag for FF42 as this a memory leak issue.
Andrew, I am a little confused whether the fix for this bug is in FF42 or not. This landed on 6/29 in m-c, I believe that was FF41 at that point in time. So, is this fix in 41 and 42 both? Or just 41?
Flags: needinfo?(continuation)
That's odd. I guess I got confused somehow. You are right, it looks like landed on m-c when it was 41, so 42 shouldn't be affected.

Here's the patch in Aurora and m-c:
Flags: needinfo?(continuation)
Blocks: GhostWindows
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.