Huge memory consumption when viewing youtube video's in html5 player mode.

RESOLVED INCOMPLETE

Status

()

defect
P1
normal
RESOLVED INCOMPLETE
5 years ago
4 years ago

People

(Reporter: dephobin, Unassigned)

Tracking

(Blocks 3 bugs)

33 Branch
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(4 attachments)

Reporter

Description

5 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141011015303

Steps to reproduce:

Open ONE tab with YouTube site (without any other sites and Firefox browser doesn't have any extension or addons) and started watching a video in 720p (approximate duration - 40 min.). YouTube site is in HTML5 player mode! (Flash player doesn't installed on the system).


Actual results:

After ~15 min. of watching video, Firefox GUI begins to slow down with partial disappearance of the GUI elements. In Task Manager, memory consumption by Firefox process is about ~3 GB of 4 GB. When I open 'about:memory' tab and see that gpu-shared is 1,5 GB and vsize - ~3,5 GB! memory-report.json.gz file is attached.
Reporter

Comment 1

5 years ago
PC: Toshiba Satelite C660-1TE
OS: Windows 7 Ultimate, 64 bit
RAM: 4 GB
CPU: Intel i3-2310M (2nd generation)
GPU: Embedded Intel HD 3000 (latest drivers - V15.28.22.64.3517)
Keywords: html5, mlk
Whiteboard: html5, youtube, video player, memory consumtion

Updated

5 years ago
Component: Untriaged → Video/Audio
Keywords: html5, mlk
Product: Firefox → Core
Whiteboard: html5, youtube, video player, memory consumtion

Comment 2

5 years ago
Did you test with a "fresh" profile without add-ons?

If not, could you test with a clean profile and attach a new memory log when the problem appears, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
Flags: needinfo?(dephobin)
Whiteboard: [MemShrink]
Reporter

Comment 3

5 years ago
(In reply to Loic from comment #2)
> Did you test with a "fresh" profile without add-ons?
> 
> If not, could you test with a clean profile and attach a new memory log when
> the problem appears, please.
> https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-
> firefox-profiles

As I mentioned in my first message: "Firefox browser doesn't have any extension or add-ons" and I can add to this, that Windows OS has been specially reinstalled  before test (from original MSDN ISO's with ONLY chipset, audio and video drivers + Windows updates on 10/21/2014 - no OTHER software). After that was installed Firefox browser, so the profile was created automatically and no add-ons or extensions has not been installed.
Flags: needinfo?(dephobin)
Reporter

Comment 4

5 years ago
Memory report after creation of new "fresh" profile.
Looking at the memory reports we have:
explicit allocations: ~140mb
resident: ~1800mb
gpu-shared: ~1500mb
Reporter

Comment 6

5 years ago
I checked latest release of Firefox (33.0.1) - still persist a huge memory consumption. But on a latest release of Firefox ESR (31.2.0) all work FINE.
Memory reports:
explicit allocations: ~114mb
resident: ~326mb
gpu-shared: ~87mb
Log file with memory usage of Firefox ESR (31.2.0) is attached.
Reporter

Comment 7

5 years ago
tn, could this be caused by OMTC? (bug 899785)
Whiteboard: [MemShrink] → [MemShrink:P2]
(In reply to Nicholas Nethercote [:njn] from comment #8)
> tn, could this be caused by OMTC? (bug 899785)

Maybe, Bas would be a better person to answer that I think.
Flags: needinfo?(bas)
dephobin, does the same problem happen if you change the value of layers.offmainthreadcomposition.enabled from true to false?
Flags: needinfo?(dephobin)
(In reply to Timothy Nikkel (:tn) from comment #9)
> (In reply to Nicholas Nethercote [:njn] from comment #8)
> > tn, could this be caused by OMTC? (bug 899785)
> 
> Maybe, Bas would be a better person to answer that I think.

Nical knows a lot more about this than I do, but maybe there's some overproduction scenario?
Flags: needinfo?(bas) → needinfo?(nical.bugzilla)
(In reply to Bas Schouten (:bas.schouten) from comment #11)
> Nical knows a lot more about this than I do, but maybe there's some
> overproduction scenario?

Except on b2g I don't think that we have anything that actively prevents over-producing video frames at the moment. Each 720p video frames take a lot of memory. Last time I looked at the media code, we would enqueue 10 frames (on desktop) before sending them to the compositor. It's probably a bit much, especially if some intel drivers tend to use twice the amount of memory they should for textures.

About OMTC the only two things that come to mind which could cause this are
 - if the compositor can't keep up we will overproduce and have too many video frames in memory at the same time which can quickly go wrong with 720p videos (before OMTC, overproduction would be blocked by the fact that the main thread is too busy when composition can't keep up)
 - whatever new stupid driver behavior caused by surface sharing which we didn't use to do before OMTC.
Flags: needinfo?(nical.bugzilla)
Dephobin, would you be willing to collect a trace of the memory allocations using xperf/WPT? It is somewhat time consuming but it would help us better understand the issue. Your help would be much appreciated!

Here are instructions: https://wiki.mozilla.org/Tracing_VirtualAlloc_With_Xperf
Reporter

Comment 14

5 years ago
To ALL:
I have very interesting situation now - I reinstalled the OS, drivers for chip set, video (latest for Intel HD 3000 - V15.28.22.64.3517), audio and started testing latest release of Firefox - 33.0.2. Now gpu-shared is around ~300 Mb after watching 30 min. of 42 min. video (720p, in HTML5 mode). So, now is not a such huge memory usage.

(In reply to David Major [:dmajor] (UTC+13) from comment #13)
> Dephobin, would you be willing to collect a trace of the memory allocations
> using xperf/WPT? It is somewhat time consuming but it would help us better
> understand the issue. Your help would be much appreciated!
> 
> Here are instructions:
> https://wiki.mozilla.org/Tracing_VirtualAlloc_With_Xperf

If I'll watch again the problem - be sure to perform a trace of memory.
Flags: needinfo?(dephobin)
Reporter

Comment 15

5 years ago
(In reply to David Major [:dmajor] (UTC+13) from comment #13)
> Dephobin, would you be willing to collect a trace of the memory allocations
> using xperf/WPT? It is somewhat time consuming but it would help us better
> understand the issue. Your help would be much appreciated!
> 
> Here are instructions:
> https://wiki.mozilla.org/Tracing_VirtualAlloc_With_Xperf

So, after some testing of Firefox 33.0.2 this bug appeared again. I've done memory trace, here the link: https://drive.google.com/file/d/0B4QaibcUILdxTmRsTGR0bUFQX1E
And I make new memory log when leak is appeared. It is attached.
Reporter

Comment 16

5 years ago
Reporter

Comment 17

5 years ago
And I want to add that memory leak begins not only if I watch 720p video but on 360p too.
Reporter

Comment 18

5 years ago
And one more - in my last memory log (memory-report-of-firefox-33.0.2.json.gz - I forget add .gz extension in 'Attachments' field, so please don't forget it, otherwise Firefox will not open), I open four tabs with different YouTube video and when memory leak is occurred I closed them leaving only one - about:memory tab. I did this in order to check whether the memory is released or not. In my test memory is not released.
I didn't find any obvious culprits in the logs. Could you try a couple more experiments:
* Does the problem occur if you set the preference layers.offmainthreadcomposition.enabled to false?
* Does the problem occur on the Firefox 34 beta? If it does, please wait until memory reaches 4GB and crashes, and then send the crash report. Then paste the Report ID from about:crashes into this bug.
Thanks!
Flags: needinfo?(dephobin)
Blocks: gfx-oom
i'm having the same issue with Youtube HTML5 video.

i have a test run with about:memory dumps and Windows Performance logs if you'd like it.
(In reply to jim_taylor_berlin from comment #20)
> i'm having the same issue with Youtube HTML5 video.
> 
> i have a test run with about:memory dumps and Windows Performance logs if
> you'd like it.

this is with FF 33.1.1, clean profile, all plugins disabled
here's a crash report that occurred while watching 2 HTML5 films on Youtube:

https://crash-stats.mozilla.com/report/index/c36ec776-6bbb-40d1-bc5c-b72732141130

it crashed when i attempted to close the browser after the UI had broken completely but the browser was still running in some kind of zombie state.
> i have a test run with about:memory dumps and Windows Performance logs if you'd like it.

Yes those would be great. I won't be able to look until next week, but maybe someone else can jump in during the meantime.
Jim: Your report at comment 22 showed nearly 3GB of write-combine memory. It sounds like bug 1062065, which we could definitely use help with.

Does this still happen with FF34? If so, an xperf/WPR trace would be really useful. Possibly also a VMMap log if you have time. Thanks!
Flags: needinfo?(jim_taylor_berlin)
ajones: does this need to block bug 1083588?
Flags: needinfo?(ajones)
Blocks: MSE
Flags: needinfo?(ajones)
Priority: -- → P1
A log from GPUView might reveal what's going on here.

You should be able to run GPUView by navigating to something like:

C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\gpuview

and running log.cmd to start. Run log.cmd again to stop.

You may need to install the Windows 8.1 SDK to get GPUView
The two people who could repro this have each had needinfo for about two months. The code will have seen significant change by the time we hear back. We may just want to call this incomplete.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE
For anyone following along, the investigation continues in bug 1127925 and its linked bugs.
Flags: needinfo?(jim_taylor_berlin)
Flags: needinfo?(dephobin)

Comment 30

4 years ago
Same Issue on 38.0.6 Cyberfox x64 (AMD optimized) - uBlock and Disconect addons
Custom PC
Asus M5A97 LE R2.0
AMD FX-6300
8GB(4x2GB) DDR3 @1600MHz (G.Skill RipJaws)
1TB WD Caviar Black
XFX Radeon HD 7850 GPU 5/2015 beta AMD driver

Comment 31

4 years ago
The issue persists on 39.0 on Windows 7 SP1 x86,
Intel Pentium E5200, 4GB RAM (3GB detected by OS).
Firefox DEFAULT profile.

After watching HTML5 videos (mainly on Youtube) for some time, memory consumption of firefox.exe goes through the roof. Before GUI elements start to vanish and stop responding and eventually the program crashes, memory usage grows to about 1GiB of private bytes and 1.5GiB of virtual set.

Closing the tabs with the videos or clearing the cache doesn't make these values go down.

Eventually the application starts to break (GUI controls vanishing) and the process crashes.

I'm currently dealing with this by using Youtube Flash Video Player addon, which forces the use of flash player for youtube videos, but I have other annoying problems with it, so I'm eagerly awating the fix.
We may need to open another bug, but in the meantime, could you provide us with the graphics section of about:support?  Also, as the memory gets large, could you grab an about:memory report and attach it to the bug?

Comment 33

4 years ago
(In reply to skrytka92 from comment #31)
> The issue persists on 39.0 on Windows 7 SP1 x86,
> Intel Pentium E5200, 4GB RAM (3GB detected by OS).
> Firefox DEFAULT profile.
> 
> After watching HTML5 videos (mainly on Youtube) for some time, memory
> consumption of firefox.exe goes through the roof. Before GUI elements start
> to vanish and stop responding and eventually the program crashes, memory
> usage grows to about 1GiB of private bytes and 1.5GiB of virtual set.
> 
> Closing the tabs with the videos or clearing the cache doesn't make these
> values go down.
> 
> Eventually the application starts to break (GUI controls vanishing) and the
> process crashes.
> 

Same thing for me. The only way I've found to watch videos without this problem is to use FF in safe mode.
I'm going to open another bug, it is too confusing to follow here.
You need to log in before you can comment on or make changes to this bug.