1044263 - 100% cpu after html5 video ends

Status: RESOLVED WORKSFORME

(Core :: Audio/Video, defect)

Description

[Nikolay Martynov]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 (Beta/Release)
Build ID: 20140725060651

Steps to reproduce:

Go to youtube and watch any html5 video (which is all of them now)


Actual results:

After video finishes playing (i.e. playing to the end) throbber appears over the video and stays there forever.
Browser is still responsive and I can close tab or click on other links on tabs.
But browser now consumers 100% cpu and if I try to close it process will never exist.
I.e. it looks like some sort of deadlock in the browser.


Expected results:

When video finishes playing related video usually get displayed (this is youtube intention I suppose).
In any case browser should not consume 100% cpu after video finishes and it should close fine after that as well.

Comment 1

[Nikolay Martynov]

It looks like CPU consumed by thread named 'Media Decode #1'.

Back trace looks like this:
#0  mozilla::GStreamerReader::DecodeAudioData (this=0x7f195363d800) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/content/media/gstreamer/GStreamerReader.cpp:587
#1  0x00007f197e508551 in mozilla::MediaDecoderReader::RequestAudioData (this=0x7f195363d800) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/content/media/MediaDecoderReader.cpp:249
#2  0x00007f197e50905d in mozilla::MediaDecoderStateMachine::DecodeAudio (this=0x7f1953bbc000) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/content/media/MediaDecoderStateMachine.cpp:649
#3  0x00007f197e4f060d in nsRunnableMethodImpl<void (mozilla::MediaDecoderStateMachine::*)(), void, true>::Run (this=<optimized out>) at ../../dist/include/nsThreadUtils.h:391
#4  0x00007f197e503072 in mozilla::MediaTaskQueue::Runner::Run (this=0x7f1949d93be0) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/content/media/MediaTaskQueue.cpp:127
#5  0x00007f197d7e44d8 in nsThreadPool::Run (this=0x7f1952c9bf80) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/xpcom/threads/nsThreadPool.cpp:220
#6  0x00007f197d7e3571 in nsThread::ProcessNextEvent (this=0x7f1942121ea0, aMayWait=<optimized out>, aResult=0x7f1960621daf) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/xpcom/threads/nsThread.cpp:770
#7  0x00007f197d7f69c5 in NS_ProcessNextEvent (aThread=<optimized out>, aMayWait=aMayWait@entry=true) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/xpcom/glue/nsThreadUtils.cpp:265
#8  0x00007f197d9ab5aa in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0x7f193f68f5c0, aDelegate=0x7f19487f23a0) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/ipc/glue/MessagePump.cpp:355
#9  0x00007f197d99ff1e in RunHandler (this=0x7f19487f23a0) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/ipc/chromium/src/base/message_loop.cc:222
#10 MessageLoop::Run (this=this@entry=0x7f19487f23a0) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/ipc/chromium/src/base/message_loop.cc:196
#11 0x00007f197d7e712c in nsThread::ThreadFunc (aArg=0x7f1942121ea0) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/xpcom/threads/nsThread.cpp:347
#12 0x00007f19821547c3 in _pt_root (arg=0x7f19438638a0) at /build/buildd/firefox-trunk-34.0~a1~hg20140725r195906/./nsprpub/pr/src/pthreads/ptthread.c:212
#13 0x00007f1982f5d182 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#14 0x00007f1982c8a30d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Comment 2

[Duncan Keall]

I'm also seeing this bug, starting in Firefox 33. My stack trace is very similar, always hanging inside mozilla::GStreamerReader::DecodeAudioData.

It seems to only affect H.264 video. Here is a video which reliably causes this bug:
https://videos.cdn.mozilla.net/brand/Mozilla_2011_Story.mp4

Whereas this version is fine:
https://videos.cdn.mozilla.net/brand/Mozilla_2011_Story.webm

I also tested stripping each of the audio and video tracks individually with ffmpeg, but the bug only appears when both audio and video are present.

Just to clarify Nikolay's comment, the bug only happens when the video finishes playing completely. Closing the tab or navigating away from the page before the video finishes doesn't trigger it.

Finally, I'm running Arch Linux x86_64 and can only cause this bug with Aurora builds from this third-party repo:
http://pkgbuild.com/~heftig/packages/aurora/

The official Mozilla builds of Aurora and Nightly don't have this problem. Currently I'm trying to rebuild the packages myself to narrow down on the change that caused it.

Here's a summary of the builds I have tested:

From heftig:
  aurora-32.0a2+20140713+gbe6908f-1 - no bug
    aurora-32.0a2+20140715+g323e7d8-1 - no bug
    aurora-33.0a2+20140724+ga3d6e45-1 - bug
    aurora-33.0a2+20140725+ga502ed4-1 - bug
    aurora-33.0a2+20140726+g797a26b-1 - bug

From Mozilla:
  nightly 33.0a1 2014-07-19 - no bug
    nightly 34.0a1 2014-07-25 - no bug
    nightly 34.0a1 2014-07-26 - no bug
    aurora  33.0a2 2014-07-25 - no bug

Comment 3

[Duncan Keall]

I've rebuilt Firefox from source and can reproduce this bug. It only appears when built with GStreamer, there is no problem when using OpenH264.

I'm going to try some earlier builds and find when this bug was introduced.

Comment 4

[Duncan Keall]

Bisecting points me to this changeset:
https://hg.mozilla.org/mozilla-central/rev/5519fd827576

> The first bad revision is:
> changeset:   189255:5519fd827576
> user:        Chris Pearce <[e-mail]>
> date:        Wed Jun 18 17:07:02 2014 +1200
> summary:     Bug 979104 - MediaDecoderReader/StateMachine asynchronous decoding. r=kinetik

There's a lot going on in that changeset, I'm not quite sure how to tackle it.

Comment 6

[Jonny Barnes]

I seem to have fixed the 100% CPU usage in heftig's builds by playing with some about:config settings.

I've set
* media.eme.enabled to true
* media.gstreamer.enabled to false
* media.mediasource.enabled to true

However, now I'm in the situation of only being able to play videos at 360p with YouTube's HTML5 player.

Comment 7

[JW Wang [:jwwang] [:jw_wang]]

It could be a dup of bug 1034957. Did the problem happen on firefox with gstreamer 1.0 as well?

Comment 8

[Duncan Keall]

Yes, it looks like this is a dup of bug 1034957.

I tested the patch from that bug report and it fixes the problem for me too. Thanks!

Comment 9

[Paul Silaghi, QA [:pauly]]

(In reply to Duncan Keall from comment #8)
> Yes, it looks like this is a dup of bug 1034957.
> 
> I tested the patch from that bug report and it fixes the problem for me too.
> Thanks!
Nikolay, can you confirm too ?

Comment 10

[Nikolay Martynov]

I'm sorry, I'm currently away with very patch access to Internet. I'll be able to test/confirm next week.
Sorry about that.

Comment 11

[Nikolay Martynov]

Cannot reproduce with latest trunk. Thanks!