Closed Bug 1087043 Opened 6 years ago Closed 6 years ago
Huge memory consumption when viewing youtube video's in html5 player mode
50.49 KB, application/gzip
50.82 KB, application/gzip
48.66 KB, application/gzip
35.66 KB, application/x-gzip
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.
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 - V184.108.40.206.3517)
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
(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.
Memory report after creation of new "fresh" profile.
Looking at the memory reports we have: explicit allocations: ~140mb resident: ~1800mb gpu-shared: ~1500mb
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.
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.
dephobin, does the same problem happen if you change the value of layers.offmainthreadcomposition.enabled from true to false?
(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.
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
To ALL: I have very interesting situation now - I reinstalled the OS, drivers for chip set, video (latest for Intel HD 3000 - V220.127.116.11.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.
(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.
And I want to add that memory leak begins not only if I watch 720p video but on 360p too.
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!
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!
ajones: does this need to block bug 1083588?
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
Depends on: 1050031
No longer depends on: 1050031
Does bug 1123535 fix this issue?
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
Closed: 6 years ago
Resolution: --- → INCOMPLETE
For anyone following along, the investigation continues in bug 1127925 and its linked bugs.
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
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?
(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.
5 years ago
You need to log in before you can comment on or make changes to this bug.