Closed
Bug 1329630
Opened 8 years ago
Closed 8 years ago
Firefox constantly uses 100% CPU after long time movie browsing, even after closing movies
Categories
(Core :: Audio/Video: Playback, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla55
Tracking | Status | |
---|---|---|
firefox-esr45 | --- | unaffected |
firefox52 | --- | unaffected |
firefox-esr52 | --- | unaffected |
firefox53 | + | unaffected |
firefox54 | + | verified |
firefox55 | + | verified |
People
(Reporter: Virtual, Assigned: jwwang)
References
()
Details
(5 keywords, Whiteboard: [fixed by patches from bug #1344772])
Attachments
(5 files)
STR:
1. Do the long time browsing session with many movies in HTML5 media format on YouTube or other streaming website.
2. After some time, like 15-30min typically, you will enjoy that Firefox constantly uses 100% of your CPU, even after closing all tabs and windows with staying with the white blank one.
[Tracking Requested - why for this release]: Regression
Reporter | ||
Comment 2•8 years ago
|
||
Just to add, that it's still happens with disabled: e10s, GPU Process (content) and GPU Process (media).
Reporter | ||
Updated•8 years ago
|
status-firefox54:
--- → affected
tracking-firefox54:
--- → ?
Reporter | ||
Updated•8 years ago
|
Updated•8 years ago
|
Priority: -- → P1
Comment 6•8 years ago
|
||
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
I have tested your issue on latest Nightly (Build ID: 20170215030342) and could not reproduce it. I have opened about 10-15 videos from YouTube. The length of the videos varied from 1h to 3h. They were playing simultaneous in Nightly for about 30m-1h with e10s ON and OFF but the CPU usage was never above 50%. After all tabs with videos were closed, only about:home page was displayed, the CPU and memory usage returned to normal.
The two systems on which the tests were performed have:
- CPU: AMD FX(tm)-8320 Eight-Core Processor 3,5GHz ; GPU: GeForce 210 ; RAM: 16GB
- CPU: Intel i5-3470 3,2GHz ; GPU Radeon R7 360 series ; RAM: 8GB
@Virtual_ManPL, on what system did you encounter this issue? Was e10s ON or OFF? Can you provide more information about the system that you used?
Is this still reproducible on your end ? If yes, can you please retest this using latest Nightly build (https://nightly.mozilla.org/) and report back the results ? When doing this, please use a new clean Firefox profile, maybe even safe mode, to eliminate custom settings as a possible cause (https://goo.gl/AR5o9d).
Flags: needinfo?(bernesb)
Reporter | ||
Comment 7•8 years ago
|
||
(In reply to Vlad Bacia-Mociran [:VladB] from comment #6)
> @Virtual_ManPL, on what system did you encounter this issue?
> Was e10s ON or OFF?
> Can you provide more information about the system that you used?
It's in "Platform:" and Comment #2,
but I'm working on Windows 7 (64bit) with Mozilla Firefox Nightly (64bit) with enabled e10s.
Disabling e10s, GPU Process (content) and GPU Process (media) didn't have any effect.
(In reply to Vlad Bacia-Mociran [:VladB] from comment #6)
> Is this still reproducible on your end ?
Yes.
(In reply to Vlad Bacia-Mociran [:VladB] from comment #6)
> If yes, can you please retest this using
> latest Nightly build (https://nightly.mozilla.org/)
> and report back the results ?
It's reproducible in latest Mozilla Firefox Nightly 54.0a1 (2017-02-15) (64-bit).
(In reply to Vlad Bacia-Mociran [:VladB] from comment #6)
> When doing this, please use a new clean Firefox profile,
It's reproducible with clean new fresh profile without any addons (extensions and plugins).
(In reply to Vlad Bacia-Mociran [:VladB] from comment #6)
> maybe even safe mode, to eliminate custom settings
> as a possible cause (https://goo.gl/AR5o9d).
It's reproducible in Safe Mode.
I also attached profile in which something could be useful and maybe will gave us some hint to find to culprit.
Moreover looks like I'm not the only one with this problem - http://forums.mozillazine.org/viewtopic.php?p=14733149#p14733149
Flags: needinfo?(Virtual)
Reporter | ||
Comment 8•8 years ago
|
||
I redone my test and profile is here - https://perfht.ml/2miAGVr + attached in Comment 8
Taken with Gecko Profiler 2.0.31 with these settings:
- Interval = 0,01ms
- Buffer size = 900MB
- Threads = GeckoMain,Compositor
- Features = Stack walk, JavaScript, Task tracer
Updated•8 years ago
|
Flags: needinfo?(rjesup)
Comment 9•8 years ago
|
||
can you re-run a profiler with e10s disabled?
Flags: needinfo?(jyavenard) → needinfo?(Virtual)
Updated•8 years ago
|
Flags: needinfo?(rjesup)
Reporter | ||
Comment 10•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #9)
> can you re-run a profiler with e10s disabled?
Sure. Have a look, profile is here - https://perfht.ml/2lbOT5A + attached in comment #10
Flags: needinfo?(Virtual)
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(jyavenard)
Reporter | ||
Comment 11•8 years ago
|
||
I done again my test with e10s enabled, when issue appeared I closed all tabs and windows, so only New Tab remain and started catching profile without doing anything for over 1min.
Profile is here - https://perfht.ml/2lSHYSG + attached in Comment 11
Taken with Gecko Profiler 2.0.31 with these settings:
- Interval = 0,01ms
- Buffer size = 900MB
- Threads = GeckoMain,Compositor
- Features = Stack walk, JavaScript, Task tracer
Comment 12•8 years ago
|
||
I'm afraid all that tells us is that the thread using the CPU isn't Main or Compositor, which isn't surprising.
Perhaps with Threads= (empty); I *think* that will capture all nsThreads. If I had a build in a debugger, I'd just hit break and see what thread it was in.
Comment 13•8 years ago
|
||
Generating a crashdump/crashreport with https://addons.mozilla.org/en-US/firefox/addon/crash-me-now-simple/ might tell us what thread if ilooping. (I suggest getting several crashes this way so we can correlate what threads appear active)
Flags: needinfo?(Virtual)
Reporter | ||
Comment 14•8 years ago
|
||
Should I get these profiles and crashes now with e10s enabled or disabled, or it just doesn't matter?
Flags: needinfo?(Virtual) → needinfo?(rjesup)
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(Virtual)
Comment 15•8 years ago
|
||
e10s - from your discussion above, doesn't matter. I'd suggest verifying you're successfully capturing a lot more threads before working to repro in a profile.
Flags: needinfo?(rjesup)
Comment 17•8 years ago
|
||
Alice0075; are you able to reproduce the problem?
Seeing you're the champion of regression finding? Could you identify this one?
Thank you
Flags: needinfo?(alice0775)
Comment 18•8 years ago
|
||
(In reply to Jean-Yves Avenard [:jya] from comment #17)
> Alice0075; are you able to reproduce the problem?
> Seeing you're the champion of regression finding? Could you identify this
> one?
> Thank you
I watched youtube play list ( https://www.youtube.com/watch?v=ydKcKJIq6AI&list=PUxVlUVEiwY43qLhCB7kMBIw , contains 200 videos) for 1hr.
However,
I could not reproduce the problem on Nightly54.0a1 32bit on Windows10 64bit and Windows7 64bit VM.
After closing the youtube tab, the CPU utilization drops normally.
Flags: needinfo?(alice0775)
Comment 19•8 years ago
|
||
Any other ideas on how to move forward? I suspect we need someone to repro it (or show it no longer repros).
Flags: needinfo?(jyavenard)
Reporter | ||
Comment 21•8 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #15)
> e10s - from your discussion above, doesn't matter. I'd suggest verifying
> you're successfully capturing a lot more threads before working to repro in
> a profile.
Unfortunately for me this will be impossible due to the same issue mentioned by me in bug #1300235 comment #37, which is the bug #1344576. I will try some other things mentioned bug #1300235 comment #39 to omit this.
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(Virtual)
Reporter | ||
Updated•8 years ago
|
status-firefox55:
--- → affected
tracking-firefox55:
--- → ?
Reporter | ||
Comment 22•8 years ago
|
||
I finally caught the working no crashy profile - https://perfht.ml/2nj6wTj + attached in Comment 22
Taken with Gecko Profiler 2.0.34 with these settings:
- Interval = 100ms
- Buffer size = 90MB
- Threads = ,
- Features = Stack walk
Flags: needinfo?(rjesup)
Flags: needinfo?(jyavenard)
Updated•8 years ago
|
Reporter | ||
Updated•8 years ago
|
Keywords: nightly-community
Reporter | ||
Updated•8 years ago
|
Has STR: --- → yes
Comment 23•8 years ago
|
||
The only threads I see that aren't 100% waiting appear to be MediaPlayback threads. waiting on semaphores some, etc, generally called from TaskQueue::Runner::Run() -> Dispatch() -> nsSharedThreadPool::Dispatch
Flags: needinfo?(rjesup)
Comment 24•8 years ago
|
||
JW,
Can you help check this bug?
This is marked as 53 regression bug. We need to check it in priority.
Thanks.
Flags: needinfo?(jyavenard) → needinfo?(jwwang)
Assignee | ||
Comment 25•8 years ago
|
||
(In reply to Virtual_ManPL [:Virtual] - (please needinfo? me) from comment #22)
> Created attachment 8846427 [details]
> Firefox 2017-03-12 19.07 profile.sps.json.gz
>
> I finally caught the working no crashy profile - https://perfht.ml/2nj6wTj +
> attached in Comment 22
>
> Taken with Gecko Profiler 2.0.34 with these settings:
> - Interval = 100ms
> - Buffer size = 90MB
> - Threads = ,
> - Features = Stack walk
I have the same conclusion as Randell. TaskQueue::Runner::Run() takes no more than 20% of the CPU time and shouldn't be the bottleneck.
I also see MediaFormatReader::NotifyDataArrived() in MediaPlayback #1 and we happen to have a bug about that which is bug 1344772.
Can you try Nightly again to see if bug 1344772 happens to fix this issue?
Flags: needinfo?(jwwang) → needinfo?(Virtual)
Reporter | ||
Comment 26•8 years ago
|
||
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #25)
> Can you try Nightly again to see if bug 1344772 happens to fix this issue?
Sure. I will report back after week of testing, to test it deeply, as it's extremely time consuming to reproduce.
Flags: needinfo?(Virtual)
Reporter | ||
Updated•8 years ago
|
Flags: needinfo?(Virtual)
Reporter | ||
Comment 27•8 years ago
|
||
After testing Mozilla Firefox Nightly for few days, I'm pretty sure that patches from bug #1344772 also fixed issues in this bug.
Blocks: 1319992
Status: NEW → RESOLVED
Has Regression Range: --- → yes
Closed: 8 years ago
status-firefox-esr45:
--- → unaffected
status-firefox-esr52:
--- → unaffected
Depends on: 1344772
Flags: needinfo?(Virtual)
Keywords: regressionwindow-wanted → power
Resolution: --- → FIXED
Whiteboard: [fixed by updated patch from bug #1344772]
Target Milestone: --- → mozilla55
Reporter | ||
Updated•8 years ago
|
Whiteboard: [fixed by updated patch from bug #1344772] → [fixed by patches from bug #1344772]
Comment 28•8 years ago
|
||
great to know.. thank you for reporting...
Reporter | ||
Comment 29•8 years ago
|
||
Per bug #1344772 comment #17, I'm marking this bug as unaffected on Firefox 53, as patch from bug #1319992, which was causing this issue was backed out from Firefox 53 in bug #1326372.
Status: RESOLVED → VERIFIED
Reporter | ||
Updated•8 years ago
|
Version: 53 Branch → 54 Branch
Reporter | ||
Updated•7 years ago
|
QA Contact: Virtual
Reporter | ||
Updated•7 years ago
|
Assignee: nobody → suro001
You need to log in
before you can comment on or make changes to this bug.
Description
•