+++ This bug was initially created as a clone of Bug #1811641 +++

Crash report: https://crash-stats.mozilla.org/report/index/8ad89e28-c397-49ab-bff6-616b70230119

Reason: EXC_BAD_ACCESS / KERN_INVALID_ADDRESS

Top 10 frames of crashing thread:

0  XUL  nsCOMPtr<nsIThreadObserver>::operator=  xpcom/base/nsCOMPtr.h:663
0  XUL  mozilla::ThreadEventQueue::PutEventInternal  xpcom/threads/ThreadEventQueue.cpp:140
0  XUL  mozilla::ThreadEventQueue::PutEvent  xpcom/threads/ThreadEventQueue.cpp:73
0  XUL  mozilla::ThreadEventTarget::Dispatch  xpcom/threads/ThreadEventTarget.cpp:122
0  XUL  nsThread::Dispatch  xpcom/threads/nsThread.cpp:676
1  XUL  nsIEventTarget::Dispatch  dist/include/nsIEventTarget.h:42
1  XUL  mozilla::camera::CamerasParent::RecvStartCapture const  dom/media/systemservices/CamerasParent.cpp:970
1  XUL  mozilla::media::LambdaRunnable<mozilla::camera::CamerasParent::RecvStartCapture  dom/media/systemservices/MediaUtils.h:77
2  XUL  nsThread::ProcessNextEvent  xpcom/ds/nsTObserverArray.h:89
3  XUL  NS_ProcessNextEvent  xpcom/threads/nsThreadUtils.cpp:473

This signature is pretty bad, but I opened a half dozen of these crashes and they all had CamerasParent::RecvStartCapture on the stack and are all on Mac OS, so I'm going to guess that this is fallout from bug 1806605.

Set release status flags based on info from the regressing bug 1806605

If we assume that assign_assuming_AddRef() would have been on the stack should the crash have occurred in that function, and that ToSupports() is a static_cast, then the crash seems to occur when reading an offset from the ThreadEventQueue ptr. The ThreadEventQueue ptr was previously successfully deferenced on the previous line in ThreadEventQueue::PutEventInternal(), implying that the ThreadEventQueue would have been destroyed while that function was running. Even if an inlined assign_assuming_AddRef() would not be on the stack, then the Release() would not be called because the oldPtr is null.

I've had a look at the crashes under these signatures and there's something that stands out: all the crash addresses start with 0x00000101, that is they all have the upper 32 bits with that pattern. It's very unlikely that this would happen randomly. Given the lack of the poison patterns I wonder if it's possible that this object has been overwritten with another object, possibly containing integer data. That would explain both the lack of the poison pattern and the odd presence of the same 32 bits everywhere.

This crash looks interesting in that it provides a bit of another data point. Thread 86 VideoCaptureAVFoundationCallback is the callback from this backend with which these crashes are happening. Thread 110 looks suspicious as well, but there should only be one callback into our code at a time since the frame queue is serial.

(In reply to Andreas Pehrson [:pehrsons] from comment #6)

This crash looks interesting in that it provides a bit of another data point. Thread 86 VideoCaptureAVFoundationCallback is the callback from this backend with which these crashes are happening. Thread 110 looks suspicious as well, but there should only be one callback into our code at a time since the frame queue is serial.

This one has a module "elgatovirtualcamera" loaded so we cannot assume it's related to the other crashes, unfortunately.

https://hg.mozilla.org/mozilla-central/rev/30340541c9a1

I'm going to try and make some changes, just so that in case these crashes are triggered by something in the frame callback (which doesn't seem unlikely, given the crash sites), it will show in crash-stats one way or another.

This patch mainly changes VideoCaptureAdapter to use an instance method to set
the capturer member under a mutex. It also moves the setting of this capturer
to start rather than init (and unsets it on stop). With this we shouldn't need
the prior fixes to RTCCameraVideoCapturer.m.

Some other cleanup happens as well:

• Constification of members
• Moving the RTCVideoFrame to webrtc::VideoFrame conversion to OnFrame()
• Optimizing away StartFrameRecording()
• Only calculating image type once

Hypothetically if the frame callback is doing something leading to crashes, this
patch should at least affect those symptoms, giving us more clues to where the
problem lies.

This patch changes away from calling the CamerasParent callback directly on the
frame queue, to notifying a MediaEvent owned by the VideoCaptureAdapter. The
frames are then handled on the video capture thread.

This patch uses StateWatching to dispatch a task to process a frame as soon as
it comes in from the VideoCaptureAdapter frame event. This is done async so that
if multiple frames come in while one is being processed, we drop all but the
latest.

https://hg.mozilla.org/mozilla-central/rev/e0d7bc989d58
https://hg.mozilla.org/mozilla-central/rev/7210a42c8ad8
https://hg.mozilla.org/mozilla-central/rev/9aa28e73aaf8
https://hg.mozilla.org/mozilla-central/rev/fe7300653e99

Appears to have worked.