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.

Let's try AV: Playback :)

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit auto_nag documentation.

Hi, Jib,
Is this something you could take a look at?
Thank you!

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?

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #4)

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?

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?

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).

Jib, can you please follow up on the above, thank you.

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.

A recent crash report from FF 97.0.1.
bp-20045022-ccff-46df-82cf-be7e00220226

Low volume linux only shutdown crash. downgrading.