Closed Bug 1050580 Opened 11 years ago Closed 10 years ago

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

Categories

(Core :: Audio/Video, defect)

x86_64
Linux
defect
Not set
normal

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
Blocks: 1056440
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: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.