Closed Bug 1213344 Opened 9 years ago Closed 8 years ago

100% CPU usage on certain page, followed by shutdown hang

Categories

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

Product:
Core
Component:
Audio/Video: Playback
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1207220

People

(Reporter: alice0775, Unassigned)

References

(
URL
)

Details

(4 keywords, Whiteboard: [parity-IE] [parity-Chrome][parity-Edge])

Attachments

(4 files)

zipped html for the record (but need network connection)
4.65 MB, application/x-zip
Details
zipped testcase
3.86 MB, application/x-zip
Details
index.html (minimum)
479 bytes, text/html
Details
crash testcase, Browser will crash by OOM
483 bytes, text/html
Details 
Chrome will not take such a high CPU utilization.
I can reproduce the HIGH CPU usage on Firefox41.0.1 as well as Nightly44.0a1.

Step To Reproduce:
1. http://game4broke.blogspot.jp/2015/10/ironside-malphite.html


Actual Results:
100% CPU usage even if stop playing the video.


Expected Results:
Should be few percent.
status-firefox41: --- → affected
status-firefox42: --- → affected
status-firefox43: --- → affected
status-firefox-esr38: --- → affected
Whiteboard: [parity-IE] [parity-Chrome][parity-Edge]
Depends on: 1213582
Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=85b2ee76f2c3&tochange=5d052a4d8f2b

Triggered by: 40b854ef9e16	Matthew Gregan — Bug 449157 - Implement loop attribute on media elements. r=roc

I think Bug 449157 exposed the existing bug. see Bug 1213582.
When I entered this page and displayed video, usage of processor increased very much in process "Plugin Container for Nightly" (70%). I often experience high usage of processor in this process and the same usage of RAM as Nightly browser process.
Second time I didn't have to display video. At once usage of processor increased to 92% in "Plugin Container for Nightly".
Attached file zipped testcase — 
testcase,

<!DOCTYPE html>
<html>
<head>
</head>
<body>
  <video autoplay="autoplay" controls="" loop="loop" preload="none" height="350" width="610">
    <source src="Ironside_Malphite_Comic.webm" type="video/webm">
    <source src="Ironside_Malphite_Comic.mp4" type="video/mp4">
    <source src="Ironside_Malphite_Comic.ogv" type="video/ogv">
  </video>
<script>
(function(){
  var container = document.querySelector('body');
  var txt;

  for (var i = 0; i < 20; i++) {
    txt = container.innerHTML;
    container.innerHTML = txt;
  }

})();
</script>
</body>
</html>
Component: Untriaged → DOM
Summary: 100% CPU usage on certain page → 100% CPU usage on certain page, ( replacing video element using innerHTML clones hidden video element )
No longer depends on: 1213582
Attached file index.html (minimum) — 
100% CPU.
Even if you pause the video, the sound won't stop.
It seems that replacing video element using innerHTML clones hidden video element.
Severity: normal → critical
Keywords: crash, testcase
100% eproducible crash when shutdown playing attachment 8673394 [details] with disabled e10s


STR
1. Disabled e10s
2. Open attachment 8673394 [details]
3. Wait for about 70 sec
4. Close Browser by clicking  [x] button in title bar

Actual Results:
bp-0f39f2d3-4e37-44bf-a586-144d12151022

bp-851fe019-4abb-4378-9092-f78a42151022
bp-a5c1fbac-1569-4912-8aec-cd61c2151022
Crash Signature: [@ mozalloc_abort | NS_DebugBreak | mozilla::layers::PImageBridgeChild::Write]
tracking-firefox42: --- → ?
tracking-firefox43: --- → ?
tracking-firefox44: --- → ?
Summary: 100% CPU usage on certain page, ( replacing video element using innerHTML clones hidden video element ) → shutdown crash in mozalloc_abort | NS_DebugBreak | mozilla::layers::PImageBridgeChild::Write and 100% CPU usage on certain page, ( replacing video element using innerHTML clones hidden video element )
Anthony, could you help here? (maybe it is not your team but it looks like stuff that you know :)
Tracking as it is a crash.
status-firefox41: affected → wontfix
tracking-firefox42: ? → +
tracking-firefox43: ? → +
tracking-firefox44: ? → +
Flags: needinfo?(ajones)
Chris - who would be the best person to look into this?
Flags: needinfo?(cpearce)
42 is going to be released with this bug. However, happy to take a patch in 43.
status-firefox42: affected → wontfix
See also bp-d9398f12-84c8-461b-b374-f9f882151027 in linux-x86_64 SeaMonkey nightly dated yesterday... let me find back the Build ID and CSIDs...

20151026003002
http://hg.mozilla.org/mozilla-central/rev/d53a52b39a95dced722cca90ac74529b66dd5253
http://hg.mozilla.org/comm-central/rev/b36d991075f1

This happened on closedown, after Ctrl+Q followed by [Quit] (i.e. with no session save) in the multitab alert. (I had just saved my session as the homepage.)
OS: Windows 7 → All
Hardware: Unspecified → All
QA Whiteboard: [seamonkey-2.41-affected]
Duplicate bug 1218205 was on restarting from Safe Mode into normal "unsafe" mode, which is possible on SeaMonkey because the are-you-sure dialog for "Help → Restart with Add-ons Disabled" has a checkbox, "[x] Restart with Add-ons Disabled".
This is at the moment browser weekly topcrash #44 for Firefox 44.0a1 and #15 for SeaMonkey 2.41a1; new in the list for both, and seen on (at least) W32, W64, L64, Android-arm and Android-x86. Not (yet) on Mac AFAICT.
Keywords: topcrash
Summary: shutdown crash in mozalloc_abort | NS_DebugBreak | mozilla::layers::PImageBridgeChild::Write and 100% CPU usage on certain page, ( replacing video element using innerHTML clones hidden video element ) → 100% CPU usage on certain page, ( replacing video element using innerHTML clones hidden video element )
Andrew, can you help us find someone to work on this topcrash? We have a test case, and lots of info here, but no one assigned to the bug.  Thanks!
Flags: needinfo?(overholt)
> It seems that replacing video element using innerHTML clones hidden video element.

It doesn't clone it, but it does create a new one and remove the old one from the DOM.

That is, the script in comment 6 is basically equivalent to:

  var v = document.querySelector("video");
  for (var i = 0; i < 20; i++) {
    var newv = document.createElement("video");
    // set the right attributes on newv
    v.parentNode.replaceChild(newv, v);
    v = newv;
  }

from the DOM point of view.

What the media code should do with this, I'm not sure.  Should removing a <video> from the DOM pause it or anything like that?
Component: DOM → Audio/Video
Flags: needinfo?(overholt)
Related to the problem where we close the tab but don't release the video resources.

Jean-Yves or Chris, do you have time to look at this?
Flags: needinfo?(jyavenard)
Priority: -- → P1
Not sure if this is related but in 44 (aurora)

I can hit a 100% CPU usage which renders firefox unusable and require a force-quit by doing the following:

load http://people.mozilla.org/~jyavenard/tests/h264.html
press play, wait until the data is fully buffered
press refresh
now close tab
go into preferences, advanced -> clear the Cached Web Content and Offline Web Content and User Data.
Now go into Privacy, and clear the history.

Typically there, the UI will become unresponsive, CPU usage is at 100%.
If that doesn't happen immediately, opening a new tab and loading  http://people.mozilla.org/~jyavenard/tests/h264.html will do it.

I can reproduce it locally 100% of the time now.
Component: Audio/Video → Audio/Video: Playback
JW, is this something you could look into? you have much more knowledge about HTMLMediaElement than I do...
Flags: needinfo?(jyavenard) → needinfo?(jwwang)
The perf report on Linux:
+    3.46%     0.00%  MediaPD~oder #5  firefox                     [.] imalloc                                                                                                ◆
+    3.46%     0.00%  MediaPD~oder #5  firefox                     [.] je_malloc                                                                                              ▒
+    3.45%     0.00%  MediaPD~oder #5  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.44%     0.22%  MediaPD~oder #5  firefox                     [.] huge_palloc                                                                                            ▒
+    3.42%     0.00%  MediaPD~der #10  firefox                     [.] je_malloc                                                                                              ▒
+    3.42%     0.00%  MediaPD~der #10  firefox                     [.] imalloc                                                                                                ▒
+    3.42%     0.00%  MediaPD~oder #1  firefox                     [.] je_malloc                                                                                              ▒
+    3.41%     0.00%  MediaPD~oder #1  firefox                     [.] imalloc                                                                                                ▒
+    3.40%     0.00%  MediaPD~oder #1  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.40%     0.00%  MediaPD~der #10  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.40%     0.20%  MediaPD~oder #1  firefox                     [.] huge_palloc                                                                                            ▒
+    3.40%     0.21%  MediaPD~der #10  firefox                     [.] huge_palloc                                                                                            ▒
+    3.38%     0.00%  MediaPD~der #11  firefox                     [.] je_malloc                                                                                              ▒
+    3.38%     0.00%  MediaPD~oder #6  firefox                     [.] je_malloc                                                                                              ▒
+    3.38%     0.00%  MediaPD~der #11  firefox                     [.] imalloc                                                                                                ▒
+    3.38%     0.00%  MediaPD~oder #6  firefox                     [.] imalloc                                                                                                ▒
+    3.37%     0.00%  MediaPD~oder #3  firefox                     [.] je_malloc                                                                                              ▒
+    3.37%     0.00%  MediaPD~oder #3  firefox                     [.] imalloc                                                                                                ▒
+    3.37%     0.00%  MediaPD~der #11  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.36%     0.00%  MediaPD~oder #6  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.36%     0.20%  MediaPD~der #11  firefox                     [.] huge_palloc                                                                                            ▒
+    3.36%     0.21%  MediaPD~oder #6  firefox                     [.] huge_palloc                                                                                            ▒
+    3.36%     0.00%  MediaPD~oder #3  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.36%     0.20%  MediaPD~oder #3  firefox                     [.] huge_palloc                                                                                            ▒
+    3.36%     0.00%  MediaPD~oder #9  firefox                     [.] imalloc                                                                                                ▒
+    3.36%     0.00%  MediaPD~oder #9  firefox                     [.] je_malloc                                                                                              ▒
+    3.35%     0.00%  MediaPD~oder #9  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.35%     0.00%  MediaPD~oder #8  firefox                     [.] je_malloc                                                                                              ▒
+    3.35%     0.21%  MediaPD~oder #9  firefox                     [.] huge_palloc                                                                                            ▒
+    3.35%     0.00%  MediaPD~oder #8  firefox                     [.] imalloc                                                                                                ▒
+    3.34%     0.00%  MediaPD~der #12  firefox                     [.] je_malloc                                                                                              ▒
+    3.34%     0.00%  MediaPD~der #12  firefox                     [.] imalloc                                                                                                ▒
+    3.33%     0.00%  MediaPD~oder #4  firefox                     [.] imalloc                                                                                                ▒
+    3.33%     0.00%  MediaPD~oder #4  firefox                     [.] je_malloc                                                                                              ▒
+    3.33%     0.00%  MediaPD~oder #8  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.33%     0.20%  MediaPD~oder #8  firefox                     [.] huge_palloc                                                                                            ▒
+    3.33%     0.00%  MediaPD~der #12  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.33%     0.20%  MediaPD~der #12  firefox                     [.] huge_palloc                                                                                            ▒
+    3.33%     0.00%  MediaPD~oder #4  libxul.so                   [.] _ZN7mozilla6layers17BufferTextureData20CreateWithBufferSizeEPNS0_17ISurfaceAllocatorENS_3gfx13SurfaceFo▒
+    3.33%     0.20%  MediaPD~oder #4  firefox                     [.] huge_palloc                                                                                            ▒

It looks like our media threads spend much time in malloc and texture/surface stuff.
Flags: needinfo?(jwwang)
there are over 20 h264 decoders running in a loop decoding continuously... that's what all those 3.3% threads are doing..
(In reply to Boris Zbarsky [:bz] (Vacation until Jan 4) from comment #19)
> > It seems that replacing video element using innerHTML clones hidden video element.
> 
> It doesn't clone it, but it does create a new one and remove the old one
> from the DOM.
> 
> That is, the script in comment 6 is basically equivalent to:
> 
>   var v = document.querySelector("video");
>   for (var i = 0; i < 20; i++) {
>     var newv = document.createElement("video");
>     // set the right attributes on newv
>     v.parentNode.replaceChild(newv, v);
>     v = newv;
>   }
> 
> from the DOM point of view.
> 
> What the media code should do with this, I'm not sure.  Should removing a
> <video> from the DOM pause it or anything like that?

A media element can continue playing even if it is detached from the DOM tree. Therefore we end up with dozens of media elements playing at the same time and consuming lots of CPU.

Not sure if we should allow playing of these hidden media elements. But we do have some test cases relying on this behavior.
IIRC, there is a bug about stop video decoding when a media element is hidden. I think it should help this case.
Too late for 43.  Are 45 and 46 affected? 
What is the possibly related bug?
status-firefox43: affected → wontfix
status-firefox45: --- → ?
status-firefox46: --- → ?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #27)
> Too late for 43.  Are 45 and 46 affected? 
> What is the possibly related bug?

Don't know. The shutdown crash which I experienced at comment 13 sqq is extremely sporadic. It was duped here at a time when this bug had a different Summary. The crash signature is the same, but IIRC I've been told this signature is rather generic, so it might be due to a different problem. I didn't check the CPU% before those crashes took me by surprise.
[Tracking Requested - why for this release]: requesting that we un-track this, but marking it as tracking? to ensure that someone in relman gets flagged to approve un-tracking this. See below for rationale...



(In reply to Alice0775 White from comment #9)
> 100% eproducible crash when shutdown playing attachment 8673394 [details]
> with disabled e10s
> 
> 
> STR
> 1. Disabled e10s
> 2. Open attachment 8673394 [details]
> 3. Wait for about 70 sec
> 4. Close Browser by clicking  [x] button in title bar
> 
> Actual Results:
> bp-0f39f2d3-4e37-44bf-a586-144d12151022
> 
> bp-851fe019-4abb-4378-9092-f78a42151022
> bp-a5c1fbac-1569-4912-8aec-cd61c2151022

This looks like the problem we fixed in bug 1207220; media trying to use gfx after gfx has shutdown.

The issue we should look at in this bug is the reduced testcase alice reported in comment 6. In this testcase, the site creates a lot of videos, and we mustn't be pausing them when they're removed from the DOM.

Given this bug is not a shutdown crash (but noted that the shutdown crash fixed in bug 1207220 was able to repro easier with this testcase), I don't think we need to track 44-46 on this bug.

So I'm removing the association with the shutdown crash here.




(In reply to Boris Zbarsky [:bz] (Vacation until Jan 4) from comment #19)
> Should removing a <video> from the DOM pause it or anything like that?

Yes, removing a <video> from the DOM should cause it to pause. This is the problem we should address in this bug.

The w3 spec[1] says:

<quote>
When a media element is removed from a Document, the user agent must run the following steps:

1. Asynchronously await a stable state, allowing the task that removed the media element from the Document to continue. The synchronous section consists of all the remaining steps of this algorithm. (Steps in the synchronous section are marked with ⌛.)

2. ⌛ If the media element is in a Document, abort these steps.

3. ⌛ If the media element's networkState attribute has the value NETWORK_EMPTY, abort these steps.

4. ⌛ Pause the media element.
</quote>

We're supposed to pause playback in HTMLMediaElement::UnbindFromTree(). Not sure why that's not being hit here.

[1] http://dev.w3.org/html5/spec-preview/media-elements.html
Crash Signature: [@ mozalloc_abort | NS_DebugBreak | mozilla::layers::PImageBridgeChild::Write]
tracking-firefox44: + → ?
Flags: needinfo?(cpearce)
UnbindFromTree has
  if (!mPaused && mNetworkState != nsIDOMHTMLMediaElement::NETWORK_EMPTY) {
    Pause();
  }
Is it possible that mNetworkState is NETWORK_EMPTY?
Flags: needinfo?(ajones)
mNetworkState is typically NETWORK_LOADING. The problem is that mPaused is true when UnbindFromTree runs. Playback is started by autoplay, which is we activate once the first frame has loaded, which happens some time after the media element is removed from the document.

The W3 spec for what to do when a media element is removed from a document says we await a stable state and pause. Currently we only pause if mPaused==false. If we called pause() irrespective of the state of our mPaused field, we'd run the pause() algorithm, as we're required to do by the spec, and which would disable autoplay for the media element being removed.
Untracking from comment 29 and marking wontfix for 44 since we are late in beta and this doesn't sound like a priority for uplift to 44. 

Maybe it would be good to put the new work into a new bug. What are you aiming for now?  Fixes to comply with specs, in 46?
status-firefox44: affected → wontfix
tracking-firefox44: ? → -
Flags: needinfo?(cpearce)
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #34)
> Untracking from comment 29 and marking wontfix for 44 since we are late in
> beta and this doesn't sound like a priority for uplift to 44. 
> 
> Maybe it would be good to put the new work into a new bug. What are you
> aiming for now?  Fixes to comply with specs, in 46?

Yes, I'm aiming to fix the issue originally reported in this bug in comment 0; Firefox uses a lot of memory in the testcase attached to this bug.

I can move the work to another bug so that it's clear what we're fixing and why/how.
Flags: needinfo?(cpearce)
That's fine, as long as you're clear on it and can mark this bug for which versions are affected and so on. Thanks chris!
Will dupe this against bug 1207220, since that fixed the issue people were most concerned about with this bug.

I'll address the high CPU usage issue in a Bug 1239899.
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox41: wontfix → ---
status-firefox42: wontfix → ---
status-firefox43: wontfix → ---
status-firefox44: wontfix → ---
status-firefox45: ? → ---
status-firefox46: ? → ---
status-firefox-esr38: affected → ---
tracking-firefox42: + → ---
tracking-firefox43: + → ---
tracking-firefox44: - → ---
Priority: P1 → --
Resolution: --- → DUPLICATE
Summary: 100% CPU usage on certain page, ( replacing video element using innerHTML clones hidden video element ) → 100% CPU usage on certain page, followed by shutdown hang
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: