Crash in [@ mozilla::MediaEngineRemoteVideoSource::Stop]
Categories
(Core :: WebRTC, defect)
Tracking
()
People
(Reporter: gsvelto, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: crash)
Crash Data
This bug is for crash report bp-901c1ae5-25e4-4659-8dfd-448f30200623.
Top 9 frames of crashing thread:
0 libxul.so mozilla::MediaEngineRemoteVideoSource::Stop dom/media/webrtc/MediaEngineRemoteVideoSource.cpp:359
1 libxul.so mozilla::media::LambdaTask<mozilla::SourceListener::StopTrack dom/media/systemservices/MediaTaskUtils.h:32
2 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1234
3 libxul.so mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:332
4 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
5 libxul.so base::Thread::ThreadMain ipc/chromium/src/base/thread.cc:192
6 libxul.so ThreadFunc ipc/chromium/src/base/platform_thread_posix.cc:40
7 libpthread.so.0 start_thread /build/glibc-OTsEL5/glibc-2.27/nptl/pthread_create.c:463
8 libc.so.6 clone
Very low volume (possibly because it's a diagnostic assertion) but there's at least two users experiencing this. The raw crash reason is MOZ_DIAGNOSTIC_ASSERT(false) (Stopping a started capture failed)
Comment 1•4 years ago
|
||
I'm not that familiar with this code, but from what I can track down, it looks like the failure is happening here: https://searchfox.org/mozilla-central/rev/a87a1c3b543475276e6d57a7a80cb02f3e42b6ed/dom/media/systemservices/CamerasParent.cpp#199. If so, it looks the video capture thread has already gone away.
Jib, any thoughts on this one?
Comment 2•4 years ago
|
||
Bumping over to Andreas in case he has any suggestions.
Comment 3•4 years ago
|
||
(In reply to Dan Minor [:dminor] from comment #1)
I'm not that familiar with this code, but from what I can track down, it looks like the failure is happening here: https://searchfox.org/mozilla-central/rev/a87a1c3b543475276e6d57a7a80cb02f3e42b6ed/dom/media/systemservices/CamerasParent.cpp#199. If so, it looks the video capture thread has already gone away.
If we're hitting that early-exit branch mChildIsAlive && mWebRTCAlive
must have been false
or we'd be hanging on the monitor. This seems to me like a legit failure path on shutdown.
We should consider dropping the assert or propagate a specific error code for when the call failed due to shutdown.
Comment 4•2 years ago
|
||
Closing because no crashes reported for 12 weeks.
Description
•