Closed Bug 1249239 Opened 8 years ago Closed 7 years ago

Multiple instances of WMF leak memory

Categories

(Core :: Audio/Video: Playback, defect, P1)

x86_64
Windows
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: shane.bundy, Assigned: cpearce, NeedInfo)

Details

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.
Can you please paste in the graphics section of about:support ?
Flags: needinfo?(shane.bundy)
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.
Flags: needinfo?(shane.bundy)
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?
Flags: needinfo?(shane.bundy)
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
Flags: needinfo?(cpearce)
Assignee: nobody → cpearce
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.
Flags: needinfo?(cpearce)
James,
Can you check if this bug still exists?
Flags: needinfo?(jacheng)
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.
Flags: needinfo?(shane.bundy)
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
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.