Leaking windows on Nightly

VERIFIED FIXED in Firefox 39

Status

()

defect
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: mccr8, Assigned: seth)

Tracking

({memory-leak, regression})

Trunk
mozilla40
Points:
---
Dependency tree / graph

Firefox Tracking Flags

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

Details

(Whiteboard: [MemShrink])

Attachments

(2 attachments)

Reporter

Description

4 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

Comment 1

4 years ago
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.
I can't reproduce this locally, but perhaps there are some US specific ads on the site, or even
mccr8 specific ads.
Reporter

Updated

4 years ago
No longer blocks: 1149752
Reporter

Updated

4 years ago
Duplicate of this bug: 1151276
Reporter

Comment 4

4 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

4 years ago
Depends on: 1151277

Comment 5

4 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

4 years ago
Whiteboard: [MemShrink]
Reporter

Comment 6

4 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

4 years ago
[Tracking Requested - why for this release]: Severe memory leaks that also result in severe pauses of a second or more.
Reporter

Updated

4 years ago
No longer depends on: 1151277
See Also: → 1151277
Assignee

Comment 8

4 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

4 years ago
Component: DOM → ImageLib
Assignee

Comment 9

4 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

4 years ago
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

4 years ago
Assignee: nobody → seth
Status: NEW → ASSIGNED
Reporter

Comment 12

4 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

4 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

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

Comment 17

4 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

4 years ago
No longer blocks: 1137019, 1139225, 1139804, 1139818, 1141819
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

4 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
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+
You need to log in before you can comment on or make changes to this bug.