Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Leaking windows on Nightly

VERIFIED FIXED in Firefox 39

Status

()

Core
ImageLib
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: mccr8, Assigned: seth)

Tracking

({mlk, regression})

Trunk
mozilla40
mlk, regression
Points:
---

Firefox Tracking Flags

(firefox38 unaffected, firefox39+ fixed, firefox40+ verified)

Details

(Whiteboard: [MemShrink])

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Steps to reproduce:
1. Open www.techcrunch.com
2. Scroll down the page.
3. Close TechCrunch.
4. Wait. (Maybe not needed.)
5. Go to about:memory, click on "Measure".  There's a non-zero value for ghost-windows in the child process, which means we're leaking windows.

I'm not sure if this reproduces in a clean profile, but I don't think I have many addons installed.
(Reporter)

Updated

2 years ago
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 1

2 years ago
Created attachment 8586886 [details]
find_roots report for a TechCrunch window

The window is being held alive by the TechCrunch document, via some onvisibilitychange listener.  I don't know what the missing reference to the TechCrunch document is.

Comment 2

2 years ago
I can't reproduce this locally, but perhaps there are some US specific ads on the site, or even
mccr8 specific ads.
(Reporter)

Updated

2 years ago
No longer blocks: 1149752
(Reporter)

Updated

2 years ago
Duplicate of this bug: 1151276
(Reporter)

Comment 4

2 years ago
Andreas is seeing this, too, so it isn't just limited to me.  Telemetry for GHOST_WINDOWS doesn't seem to show any particular increase, but my local telemetry that has a bunch of them says 0, so I guess it is broken somehow.  I'll file a bug for that.  My guess is there's some e10s issue there.
(Reporter)

Updated

2 years ago
Depends on: 1151277

Comment 5

2 years ago
I'm also suffering from ghost windows on Nightly. I have e10s off. All my ghost windows are from facebook.com
I don't have specific steps to reproduce, just browse around and make Firefox use a lot of memory.
The last time it happened, I used google maps/street view a lot (with facebook open on another tab), and after that, Nightly never released the memory used.
(Reporter)

Updated

2 years ago
status-firefox38: --- → unaffected
status-firefox39: --- → affected
Keywords: regressionwindow-wanted
Whiteboard: [MemShrink]
(Reporter)

Comment 6

2 years ago
I bisected it down locally to this push by Seth:
  https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2e9b6048bd0f&tochange=f687743cc499

The easiest way I found to reproduce it was to load techcrunch.com, then quickly close the tab while it was still loading.  It seems plausible that something goes awry that keeps the window alive when the page is closed in the middle of things.

I did have a little bit of trouble reproducing this in a fresh profile, so if this isn't enough to go on, Seth, I can do some local builds to narrow it down further.
Flags: needinfo?(seth)
(Reporter)

Comment 7

2 years ago
[Tracking Requested - why for this release]: Severe memory leaks that also result in severe pauses of a second or more.
tracking-firefox39: --- → ?
tracking-firefox40: --- → ?
(Reporter)

Updated

2 years ago
No longer depends on: 1151277
See Also: → bug 1151277
(Assignee)

Comment 8

2 years ago
I'd bet it's bug 1137037. Presumably something is keeping alive the imgCacheValidator, which now contains an nsCOMPtr to the document. Maybe the channel/request, via the ImageLib cache?
Flags: needinfo?(seth)
(Reporter)

Updated

2 years ago
Component: DOM → ImageLib
(Assignee)

Comment 9

2 years ago
I hate to say it, but I can't reproduce this locally either. I feel pretty confident about the cause of the issue, though. Andrew, hopefully you can verify the fix.
(Assignee)

Comment 10

2 years ago
Created attachment 8588876 [details] [diff] [review]
Stop leaking windows via imgCacheValidator

Here's the patch. We make sure to free imgCacheValidator::mContext in
OnStartRequest. I don't think the API allows it, but just in case we ever only
get OnStopRequest, I free it there too.
Attachment #8588876 - Flags: review?(amarchesini)
(Assignee)

Updated

2 years ago
Assignee: nobody → seth
Status: NEW → ASSIGNED
(Assignee)

Comment 11

2 years ago
https://treeherder.mozilla.org/#/jobs?repo=try&revision=921553944db6
(Reporter)

Comment 12

2 years ago
Thanks for looking at this so quickly.  I'll check tomorrow.
Flags: needinfo?(continuation)
Attachment #8588876 - Flags: review?(amarchesini) → review+
(Reporter)

Comment 13

2 years ago
I tried a few times and wasn't able to reproduce it with your patch.
Flags: needinfo?(continuation)
Keywords: mlk
https://hg.mozilla.org/integration/mozilla-inbound/rev/0e7488db2bd3

Maybe we'll get lucky and this will help with some OOM-looking issues we're having in automation too.
(Assignee)

Comment 15

2 years ago
Thanks for the review, verification, and push, everyone!
https://hg.mozilla.org/mozilla-central/rev/a93fb336e91e
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox40: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
(Assignee)

Comment 17

2 years ago
Comment on attachment 8588876 [details] [diff] [review]
Stop leaking windows via imgCacheValidator

We need this on Aurora.

Approval Request Comment
[Feature/regressing bug #]: Bug 1137037.
[User impact if declined]: Possibly major memory leaks.
[Describe test coverage new/current, TreeHerder]: On m-c.
[Risks and why]: Very low risk.
[String/UUID change made/needed]: None.
Attachment #8588876 - Flags: approval-mozilla-aurora?
(Assignee)

Updated

2 years ago
No longer blocks: 1137019, 1139225, 1139804, 1139818, 1141819
tracking-firefox39: ? → +
tracking-firefox40: ? → +
Florin can you verify this fix on Nightly based on the STR? Thanks! 
I'd like to give it another day or so on Nightly for it to bake before uplift.
Flags: needinfo?(florin.mezei)
(Reporter)

Comment 19

2 years ago
The problem seems fixed for me in Nightly.

Closing the tab while the page is still loading seems to help trigger it.
We couldn't reproduce using Nightly 40.0a1 2015-04-01 under Win 7 64-bit and Mac OS X 10.9.5.

Since for Andrew it's correctly working now (comment 19), I'm marking this as verified.
Status: RESOLVED → VERIFIED
status-firefox40: fixed → verified
Flags: needinfo?(florin.mezei)
Comment on attachment 8588876 [details] [diff] [review]
Stop leaking windows via imgCacheValidator

Approving for uplift to aurora.
Attachment #8588876 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/6d6a22b769bd
status-firefox39: affected → fixed
You need to log in before you can comment on or make changes to this bug.