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

Status: RESOLVED INCOMPLETE

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

Description

[dephobin]

Attachment: memory-report.json.gz

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.

Comment 1

[dephobin]

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)

Comment 2

[Loic]

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

Comment 3

[dephobin]

(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.

Comment 4

[dephobin]

Attachment: memory-report (with fresh profile).json.gz

Memory report after creation of new "fresh" profile.

Comment 5

[Timothy Nikkel (:tnikkel)]

Looking at the memory reports we have:
explicit allocations: ~140mb
resident: ~1800mb
gpu-shared: ~1500mb

Comment 6

[dephobin]

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.

Comment 7

[dephobin]

Attachment: memory-report (esr 31.2.0).json.gz

Comment 8

[Nicholas Nethercote [inactive]]

tn, could this be caused by OMTC? (bug 899785)

Comment 9

[Timothy Nikkel (:tnikkel)]

(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.

Comment 10

[Timothy Nikkel (:tnikkel)]

dephobin, does the same problem happen if you change the value of layers.offmainthreadcomposition.enabled from true to false?

Comment 11

[Bas Schouten (:bas.schouten)]

(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?

Comment 12

[Nicolas Silva [:nical]]

(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.

Comment 13

[(Away)]

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

Comment 14

[dephobin]

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.

Comment 15

[dephobin]

(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.

Comment 16

[dephobin]

Attachment: memory-report-of-firefox-33.0.2.json

Comment 17

[dephobin]

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

Comment 18

[dephobin]

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.

Comment 19

[(Away)]

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!

Comment 20

[jim_taylor_berlin]

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.

Comment 21

[jim_taylor_berlin]

(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

Comment 22

[jim_taylor_berlin]

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.

Comment 23

[(Away)]

> 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.

Comment 24

[(Away)]

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!

Comment 25

[Chris Pearce [:cpearce (Not reading bugmail)]]

ajones: does this need to block bug 1083588?

Comment 26

[Jeff Muizelaar [:jrmuizel]]

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

Comment 27

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Does bug 1123535 fix this issue?

Comment 28

[(Away)]

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.

Comment 29

[(Away)]

For anyone following along, the investigation continues in bug 1127925 and its linked bugs.

Comment 30

[ryanhall]

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

[skrytka92]

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.

Comment 32

[Milan Sreckovic [:milan] (needinfo for best results)]

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

[atman]

(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.

Comment 34

[Milan Sreckovic [:milan] (needinfo for best results)]

I'm going to open another bug, it is too confusing to follow here.