User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160214030236 Steps to reproduce: I was having an exchange of direct messages on Twitter and pretty soon it was filled with GIFs (Twitter transcodes them into looped MP4s). Actual results: Due to how Twitter likes to reload instances of looped GIFs occasionally this quickly ate up RAM on my machine and the content process crashed. This happens regardless of e10s being enabled or not. Expected results: It should not have crashed or leaked memory. Perhaps Firefox should've shared an instance of Windows Media Foundation to help manage memory usage better.
Component: Untriaged → Audio/Video: Playback
OS: Unspecified → Windows
Product: Firefox → Core
Hardware: Unspecified → x86_64
I should note that this is reproducible on the latest trunk build. The machine I reported this on happens to run an older build due to the poor internet connection where I am, making updates tedious.
Do you have the same problem in http://people.mozilla.org/~cpearce/stress/ ?
Can you please paste in the graphics section of about:support ?
Graphics Features Compositing Direct3D 11 Asynchronous Pan/Zoom wheel input enabled; touch input enabled WebGL Renderer Google Inc. -- ANGLE (Intel(R) HD Graphics 4600 Direct3D11 vs_5_0 ps_5_0) Hardware H264 Decoding Yes; Using D3D9 API Direct2D true DirectWrite true (6.2.9200.17568) GPU #1 Active Yes Description Intel(R) HD Graphics 4600 Vendor ID 0x8086 Device ID 0x0412 Driver Version 10.18.14.4332 Driver Date 11-20-2015 Drivers igdumdim64 igd10iumd64 igd10iumd64 igdumdim32 igd10iumd32 igd10iumd32 Subsys ID 05a41028 RAM Unknown Diagnostics ClearType Parameters D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100 ] AzureCanvasAccelerated 0 AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo ClearType Parameters D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100 ] D [ Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100 ] I can't seem to reproduce the issue I'm seeing on the stress test posted but TweetDeck, where I first experienced it, still does it. Right now it has caused plugin-container to jump to triple figures in the thread count and over 1GB in memory usage. It remains like that until I'm off TweetDeck for about a minute (some of the added threads and memory used still remains). I am using e10s, haven't tried without.
Update on the previous comment; the stress test causes memory issues when reloaded constantly.
(In reply to Shane Bundy from comment #5) > Update on the previous comment; the stress test causes memory issues when > reloaded constantly. I don't suppose you can provide steps to reproduce that I can follow?
I wonder if adding a call to JS_updateMallocCounter() in WMFVideoMFTManager::Init() would help the GC happen more often. We do that in CanvasRenderingContext2D::EnsureTarget to guard against rapid allocation of Canvas objects. See https://dxr.mozilla.org/mozilla-central/source/dom/canvas/CanvasRenderingContext2D.cpp#1645
How to reproduce use latest Firefox 49 or any previous Go to https://www.facebook.com/Google Scroll down the page, to load some players. The RAM use will rapidly grow from 200MB to 1Gb -> 2Gb -> 3Gb If you set up preference pref("media.wmf.enabled", false); Everything works fine.
tested on windows 10 Home or Pro no difference, on both memory leaks
(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #7) > I wonder if adding a call to JS_updateMallocCounter() in > WMFVideoMFTManager::Init() would help the GC happen more often. We do that > in CanvasRenderingContext2D::EnsureTarget to guard against rapid allocation > of Canvas objects. > > See > https://dxr.mozilla.org/mozilla-central/source/dom/canvas/ > CanvasRenderingContext2D.cpp#1645 I've tested this, and discovered it's not enough to save us. We'll need to get better at shutting down decoders more aggressively, so we don't have to wait for a GC to clean them up.
James, Can you check if this bug still exists?
I've tested and the memory is eaten not as rapid as comment said on Nightly. I'd like to ni mikhail to confirm. Hi mikhail, Would you please check is the memory usage is eased? Thanks.
Flags: needinfo?(jacheng) → needinfo?(mikhail.e.kulikov)
Clearing needinfo flag as I no longer use Twitter so I cannot use my test case to see if the issue can still be reproduced.
Close this bug since it cannot be reproduced now. Please feel free to reopen this bug if anyone still can see this bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.