Crash in [@ shutdownhang | __lll_lock_wait]
Categories
(Core :: WebRTC: Audio/Video, defect, P3)
Tracking
()
People
(Reporter: emilghitta, Unassigned, NeedInfo)
Details
(Keywords: crash)
Crash Data
This bug is for crash report bp-ac28a6ee-e7a6-4e5c-b25e-342c40191016.
Top 10 frames of crashing thread:
0 libpthread-2.27.so __lll_lock_wait
1 libpthread-2.27.so __pthread_mutex_lock /build/glibc-OTsEL5/glibc-2.27/nptl/../nptl/pthread_mutex_lock.c:133
2 firefox-bin mozilla::detail::MutexImpl::lock mozglue/misc/Mutex_posix.cpp:125
3 libxul.so mozilla::camera::CamerasParent::DispatchToVideoCaptureThread dom/media/systemservices/CamerasParent.cpp:188
4 libxul.so mozilla::camera::CamerasParent::StopVideoCapture dom/media/systemservices/CamerasParent.cpp:210
5 libxul.so non-virtual thunk to mozilla::camera::CamerasParent::BlockShutdown dom/media/systemservices/CamerasParent.cpp
6 libxul.so NS_InvokeByIndex
7 libxul.so XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:1149
8 libxul.so XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:946
9 libxul.so js::InternalCallOrConstruct js/src/vm/Interpreter.cpp:550
This happened to me only once and I don't have clear steps to reproduce this issue. Firefox crashed after performing browser restart multiple times on Ubuntu 18.04 64bit.
From other crash reports, this seems to happen in 69.0.2 as well.
Not sure which component fits this issue best. Please feel free to change.
Updated•5 years ago
|
Comment 2•5 years ago
|
||
The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.
Comment 3•5 years ago
|
||
Hi, Jib,
Is this something you could take a look at?
Thank you!
Comment 4•5 years ago
|
||
sThreadMonitor
is nullptr
when CamerasParent gets BlockShutdown
.
Looks like we need to lock sMutex
here too, but do we do it in BlockShutdown
or DispatchToVideoCaptureThread
?
Andreas, any preference? How come we have two locks here if we always have to lock both?
Comment 5•5 years ago
|
||
(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #4)
sThreadMonitor
isnullptr
when CamerasParent getsBlockShutdown
.Looks like we need to lock
sMutex
here too, but do we do it inBlockShutdown
orDispatchToVideoCaptureThread
?Andreas, any preference? How come we have two locks here if we always have to lock both?
Eeeh, I don't want to give guidance on code I don't know. Having two locks is a code smell already, personally I'd stay away from that.
From what I can gather though, sMutex
guards the assignment of the static members. If you're in a CamerasParent that is guaranteed alive, using them should be fine.
Why is sThreadMonitor
even static? Looks like it's there for the static thread somehow. To me this would be much simpler with a TaskQueue member (possibly a Monitor member if needed) on top of a shared thread pool.
These are from bug 1399413 that you reviewed, so I'd expect you to know better than me. Wanna clean this up a bit, and add comments on what guards what?
Comment 6•4 years ago
|
||
jib, can you implement something, maybe what you said in comment 4? And yeah, documentation about locks sounds good (or maybe refactor and use a rust-style DataMutex).
Updated•4 years ago
|
Comment 7•4 years ago
|
||
Jib, can you please follow up on the above, thank you.
Updated•4 years ago
|
Comment 8•3 years ago
|
||
The fission team is seeing a ten-fold increase of this (linux) bug with fission. So we should up-prioritize it.
While Fission removes the upper limit on processes, each eTLD+1 will be a unique process, so the additional number of shutdowns alone don't seem sufficient to explain this increase, given how camera is usually accessed (typically same-origin and not from multiple iframes at once).
More likely, this represents a timing change that this bug is sensitive to.
Comment 9•2 years ago
|
||
A recent crash report from FF 97.0.1.
bp-20045022-ccff-46df-82cf-be7e00220226
Comment 10•2 years ago
|
||
Low volume linux only shutdown crash. downgrading.
Description
•