1097883 - crash calling av.mozCaptureStreamUntilEnded() with audio already playing

Status: RESOLVED WORKSFORME

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

Description

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: STR

1. Open attached STR, wait till you hear music and hit the [Start!] button.

Media S~hine #1 (67) EXC_BAD_ACCESS (code=1, address=0x20)

  void
  BlockingResourceBase::CheckAcquire()
  {
>   if (mType == eCondVar) {
      NS_NOTYETIMPLEMENTED(
        "FIXME bug 456272: annots. to allow CheckAcquire()ing condvars");
      return;
    }

this	mozilla::BlockingResourceBase *	0x10	0x0000000000000010
chainFront	mozilla::BlockingResourceBase *	0x13f9d6000	0x000000013f9d6000
cycle	nsAutoPtr<nsTArray<const mozilla::BlockingResourceBase *> >		
out	nsAutoCString		
maybeImminent	bool	false	false

> Media S~hine #1 (67)
> #0    0x0000000101735591 in mozilla::BlockingResourceBase::CheckAcquire() at /Users/Jan/moz/mozilla-central/xpcom/glue/BlockingResourceBase.cpp:269
> #1    0x0000000101735a5f in mozilla::OffTheBooksMutex::Lock() at /Users/Jan/moz/mozilla-central/xpcom/glue/BlockingResourceBase.cpp:379
> #2    0x0000000101707e65 in mozilla::Monitor::Lock() at /Users/Jan/moz/mozilla-central/obj-x86_64-apple-darwin12.2.1-debug/xpcom/threads/../../dist/include/mozilla/Monitor.h:35
> #3    0x00000001016f71e3 in mozilla::MonitorAutoLock::MonitorAutoLock(mozilla::Monitor&) at /Users/Jan/moz/mozilla-central/obj-x86_64-apple-darwin12.2.1-debug/xpcom/threads/../../dist/include/mozilla/Monitor.h:78
> #4    0x00000001016f66bd in mozilla::MonitorAutoLock::MonitorAutoLock(mozilla::Monitor&) at /Users/Jan/moz/mozilla-central/obj-x86_64-apple-darwin12.2.1-debug/xpcom/threads/../../dist/include/mozilla/Monitor.h:79
> #5    0x0000000104163d0d in mozilla::MediaTaskQueue::IsCurrentThreadIn() at /Users/Jan/moz/mozilla-central/dom/media/MediaTaskQueue.cpp:164
> #6    0x0000000104153694 in mozilla::MediaDecoderStateMachine::OnDecodeThread() const at /Users/Jan/moz/mozilla-central/dom/media/MediaDecoderStateMachine.cpp:3182
> #7    0x000000010415f15d in mozilla::MediaDecoderStateMachine::StopAudioThread() at /Users/Jan/moz/mozilla-central/dom/media/MediaDecoderStateMachine.cpp:1602
> #8    0x00000001041638ae in mozilla::MediaDecoderStateMachine::CallRunStateMachine() at /Users/Jan/moz/mozilla-central/dom/media/MediaDecoderStateMachine.cpp:3158
> #9    0x000000010415688d in mozilla::MediaDecoderStateMachine::TimeoutExpired(void*) at /Users/Jan/moz/mozilla-central/dom/media/MediaDecoderStateMachine.cpp:3167
> #10    0x000000010416451c in mozilla::MediaDecoderStateMachineScheduler::TimeoutExpired(int) at /Users/Jan/moz/mozilla-central/dom/media/MediaDecoderStateMachineScheduler.cpp:160
> #11    0x0000000104188fcf in (anonymous namespace)::TimerEvent::Run() at /Users/Jan/moz/mozilla-central/dom/media/MediaDecoderStateMachineScheduler.cpp:23
> #12    0x00000001041890fc in non-virtual thunk to (anonymous namespace)::TimerEvent::Run() at /Users/Jan/moz/mozilla-central/dom/media/MediaDecoderStateMachineScheduler.cpp:24
> #13    0x00000001016f3c37 in nsThreadPool::Run() at /Users/Jan/moz/mozilla-central/xpcom/threads/nsThreadPool.cpp:220
> #14    0x00000001016f3d2c in non-virtual thunk to nsThreadPool::Run() at /Users/Jan/moz/mozilla-central/xpcom/threads/nsThreadPool.cpp:234
> #15    0x00000001016f0698 in nsThread::ProcessNextEvent(bool, bool*) at /Users/Jan/moz/mozilla-central/xpcom/threads/nsThread.cpp:830
> #16    0x0000000101748fc7 in NS_ProcessNextEvent(nsIThread*, bool) at /Users/Jan/moz/mozilla-central/xpcom/glue/nsThreadUtils.cpp:265
> #17    0x0000000101d86453 in mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) at /Users/Jan/moz/mozilla-central/ipc/glue/MessagePump.cpp:339
> #18    0x0000000101d1a1b5 in MessageLoop::RunInternal() at /Users/Jan/moz/mozilla-central/ipc/chromium/src/base/message_loop.cc:233
> #19    0x0000000101d1a0c5 in MessageLoop::RunHandler() at /Users/Jan/moz/mozilla-central/ipc/chromium/src/base/message_loop.cc:226
> #20    0x0000000101d1a06d in MessageLoop::Run() at /Users/Jan/moz/mozilla-central/ipc/chromium/src/base/message_loop.cc:200
> #21    0x00000001016eeb36 in nsThread::ThreadFunc(void*) at /Users/Jan/moz/mozilla-central/xpcom/threads/nsThread.cpp:350
> #22    0x0000000101371ebf in _pt_root at /Users/Jan/moz/mozilla-central/nsprpub/pr/src/pthreads/ptthread.c:212
> #23    0x00007fff91d1e899 in _pthread_body ()
> #24    0x00007fff91d1e72a in _pthread_start ()
> #25    0x00007fff91d22fc9 in thread_start ()

Of note:

#6:
  bool MediaDecoderStateMachine::OnDecodeThread() const
  {
>   return mDecodeTaskQueue->IsCurrentThreadIn();
  }

this	mozilla::MediaDecoderStateMachine *	0x12513ec00	0x000000012513ec00
  mDecodeTaskQueue 	mozilla::RefPtr<mozilla::MediaTaskQueue>		
    mPtr 	mozilla::MediaTaskQueue *	NULL	0x0000000000000000

Crashes in Nightly debug/opt builds, and Firefox Beta (URL). I'm unable to make Dev Edition and Release crash, though with it being consistent for a while, then elusive and then resurfacing, I can't be certain.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Attachment: STR

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

This is MediaDecoder/element, not WebRTC

Roc/Anthony: who should look at this?

Comment 3

[Karl Tomlinson (:karlt)]

Small null offset deref.  Not security sensitive.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Note that I don't think CheckAcquire() runs on opt builds...
though *if* the mutex value is always null in the error case, it likely leads to a different nullptr deref.

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Randell Jesup [:jesup] from comment #4)
> Note that I don't think CheckAcquire() runs on opt builds...
> though *if* the mutex value is always null in the error case, it likely
> leads to a different nullptr deref.

Yeah the opt stack in the crash report (see URL) is slightly different, but it looks like mDecodeTaskQueue is null here too: http://hg.mozilla.org/releases/mozilla-beta/annotate/7f3fa3538051/content/media/MediaDecoderStateMachine.cpp#l2509

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Looks like we went through the MediaDecoderStateMachine::RunStateMachine shutdown sequence (that's the only place we clear mDecodeTaskQueue) and then before everything disappears we get a CallRunStateMachine event which calls into StopAudioThread. We should just not call StopAudioThread there if we're already in the shutdown state.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Acutally we shouldn't do anything in StopAudioThread if mAudioSink is already null.

Comment 8

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

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6)
> Looks like we went through the MediaDecoderStateMachine::RunStateMachine
> shutdown sequence (that's the only place we clear mDecodeTaskQueue) and then
Do you mean http://hg.mozilla.org/mozilla-central/file/cf9eafef4ffa/dom/media/MediaDecoderStateMachine.cpp#l2465?

> before everything disappears we get a CallRunStateMachine event which calls
> into StopAudioThread. We should just not call StopAudioThread there if we're
> already in the shutdown state.
When shutdown sequence starts, it is impossible to schedule another run of the state machine. I wonder how CallRunStateMachine could have a chance to run under such a condition.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to JW Wang [:jwwang] from comment #8)
> (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6)
> > Looks like we went through the MediaDecoderStateMachine::RunStateMachine
> > shutdown sequence (that's the only place we clear mDecodeTaskQueue) and then
> Do you mean
> http://hg.mozilla.org/mozilla-central/file/cf9eafef4ffa/dom/media/
> MediaDecoderStateMachine.cpp#l2465?

Yes.

> > before everything disappears we get a CallRunStateMachine event which calls
> > into StopAudioThread. We should just not call StopAudioThread there if we're
> > already in the shutdown state.
> When shutdown sequence starts, it is impossible to schedule another run of
> the state machine. I wonder how CallRunStateMachine could have a chance to
> run under such a condition.

I don't know. I can't reproduce this on Linux. Maybe you could work with jib to figure this out?

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I did find bug 1097883 but that seems to be a different bug.

Comment 11

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

I will try to see if I have some luck in repro this bug.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #10)
> I did find bug 1097883 but that seems to be a different bug.

I meant bug 1098668.

Comment 13

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

Can't repro it either...

Comment 14

[Al Billings [:abillings - ex-MoCo]]

Unhiding based on comment 3.

Comment 15

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

Doesn't repro for me. Is this still an issue?

Comment 16

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

I tried to reproduce and I couldn't.

Comment 17

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

What's still odd though, is that when I hit [Start] (it appears the webm file is gone from bmoattachments, but I'm using a local version with the file) the sound of the video stops, yet the video continues. That's not supposed to happen is it?

All the button does is call v1.mozCaptureStreamUntilEnded().