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.
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.
I can't reproduce this locally, but perhaps there are some US specific ads on the site, or even mccr8 specific ads.
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.
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.
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.
[Tracking Requested - why for this release]: Severe memory leaks that also result in severe pauses of a second or more.
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?
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.
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.
Thanks for looking at this so quickly. I'll check tomorrow.
I tried a few times and wasn't able to reproduce it with your patch.
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!
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.
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.
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.
Comment on attachment 8588876 [details] [diff] [review] Stop leaking windows via imgCacheValidator Approving for uplift to aurora.