Closed Bug 1050580 Opened 5 years ago Closed 5 years ago

Crash in MediaSourceReader::Seek -> WaitForData -> PR_WaitCondVar

Categories

(Core :: Audio/Video, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: johns, Unassigned)

References

(Blocks 1 open bug)

Details

Happened to catch this in a debugger -- had played a youtube video in a tab I think was still open. Media source pref'd on.

I have a core file for this, but it was an opt build, so it may not be terribly useful

> #0  0x00007ffff7e99d37 in PR_WaitCondVar (cvar=0x7fff68b17b00, timeout=<optimized out>) at nsprpub/pr/src/pthreads/ptsynch.c:391
> #1  0x00007ffff3959428 in Wait (aInterval=<optimized out>, this=<optimized out>, aInterval=<optimized out>) at content/media/mediasource/../../../dist/include/mozilla/CondVar.h:79
> #2  Wait (aInterval=4294967295, this=<optimized out>) at ../../../dist/include/mozilla/Monitor.h:40
> #3  Wait (aInterval=<optimized out>, this=<optimized out>, aInterval=<optimized out>) at ../../../dist/include/mozilla/Monitor.h:88
> #4  WaitForData (this=<optimized out>, this=<optimized out>) at content/media/mediasource/MediaSource.cpp:407
> #5  mozilla::MediaSourceReader::Seek (this=0x7fff84eb9800, aTime=56619858, aStartTime=0, aEndTime=612333287, aCurrentTime=2366077) at content/media/mediasource/MediaSourceDecoder.cpp:524
> #6  0x00007ffff39099cd in mozilla::MediaDecoderStateMachine::DecodeSeek (this=0x7fff84eb8c00) at content/media/MediaDecoderStateMachine.cpp:2068
> #7  0x00007ffff391ef27 in nsRunnableMethodImpl<void (mozilla::MediaDecoderStateMachine::*)(), void, true>::Run (this=<optimized out>) at content/media/../../dist/include/nsThreadUtils.h:391
> #8  0x00007ffff3919e65 in mozilla::MediaTaskQueue::Runner::Run (this=0x7fff8b5238a0) at content/media/MediaTaskQueue.cpp:167
> #9  0x00007ffff20357ca in nsThreadPool::Run (this=0x7fff6942b400) at xpcom/threads/nsThreadPool.cpp:220
> #10 0x00007ffff20359cd in non-virtual thunk to nsThreadPool::Run() () at Unified_cpp_xpcom_threads0.cpp:234
> #11 0x00007ffff2033e2f in nsThread::ProcessNextEvent (this=0x7fffa47c8500, aMayWait=<optimized out>, aResult=0x7fffdc375e38) at xpcom/threads/nsThread.cpp:770
> #12 0x00007ffff230e7ae in mozilla::ipc::MessagePumpForNonMainThreads::Run (this=0x7fff69403380, aDelegate=0x7fff688c8420) at xpcom/glue/nsThreadUtils.cpp:265
> #13 0x00007ffff2032899 in nsThread::ThreadFunc (aArg=0x7fffa47c8500) at ipc/chromium/src/base/message_loop.cc:229
> #14 0x00007ffff7ea3798 in _pt_root (arg=0x7fff748d7da0) at nsprpub/pr/src/pthreads/ptthread.c:212
> #15 0x00007ffff7bc5124 in start_thread () from /usr/lib/libpthread.so.0
> #16 0x00007ffff6ecc4bd in clone () from /usr/lib/libc.so.6
MediaSourceReader::mMediaSource is a pointer to a main thread object.

If we want to use it on a decode thread, then it needs to be accessed within a mutex and cleared, probably during MediaSourceDecoder::DetachMediaSource(), with that mutex held.

But then leaving that lock held while waiting on the mWaitForDataMonitor condition variable in MediaSource::WaitForData() doesn't seem good.

The best fix here might be fix bug 1056441.
Depends on: 1056441
The patch in bug 1040563 might fix this, otherwise bug 1056441 will.
Looks resolved by bug 1040563. Open new bug if it or similar appears again.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.