crash calling av.mozCaptureStreamUntilEnded() with audio already playing

RESOLVED WORKSFORME

Status

()

--
major
RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: jib, Assigned: roc)

Tracking

({crash, csectype-nullptr})

34 Branch
All
Mac OS X
crash, csectype-nullptr
Points:
---

Firefox Tracking Flags

(firefox33 ?, firefox34 affected, firefox35 affected, firefox36 affected, firefox-esr31 ?)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

Created attachment 8521579 [details]
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.
Created attachment 8521581 [details]
STR
Attachment #8521579 - Attachment is obsolete: true
This is MediaDecoder/element, not WebRTC

Roc/Anthony: who should look at this?
Component: WebRTC: Audio/Video → Video/Audio
Flags: needinfo?(roc)
Flags: needinfo?(ajones)
Small null offset deref.  Not security sensitive.
Keywords: csectype-nullptr
Flags: needinfo?(ajones)
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.

Updated

4 years ago
Keywords: crash
(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
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.
Assignee: nobody → roc
Flags: needinfo?(roc)
Acutally we shouldn't do anything in StopAudioThread if mAudioSink is already null.
(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.
(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?
Flags: needinfo?(jwwang)
I did find bug 1097883 but that seems to be a different bug.
I will try to see if I have some luck in repro this bug.
Flags: needinfo?(jwwang)
(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.
Can't repro it either...
Unhiding based on comment 3.
Group: core-security
status-firefox33: --- → ?
status-firefox34: --- → affected
status-firefox35: --- → affected
status-firefox36: --- → affected
status-firefox-esr31: --- → ?
Component: Audio/Video → Audio/Video: Playback
Doesn't repro for me. Is this still an issue?
Flags: needinfo?(jib)
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(jib)
Resolution: --- → WORKSFORME
I tried to reproduce and I couldn't.
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().
You need to log in before you can comment on or make changes to this bug.