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)

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.
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.
No longer blocks: 1149752
Duplicate of this bug: 1151276
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.
Depends on: 1151277
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.
Whiteboard: [MemShrink]
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)
[Tracking Requested - why for this release]: Severe memory leaks that also result in severe pauses of a second or more.
No longer depends on: 1151277
See Also: → 1151277
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)
Component: DOM → ImageLib
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.
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: nobody → seth
Status: NEW → ASSIGNED
Thanks for looking at this so quickly.  I'll check tomorrow.
Flags: needinfo?(continuation)
Attachment #8588876 - Flags: review?(amarchesini) → review+
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.
Thanks for the review, verification, and push, everyone!
https://hg.mozilla.org/mozilla-central/rev/a93fb336e91e
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
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?
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)
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.