Crash in [@ nsCOMPtr<T>::operator= | mozilla::ThreadEventTarget::Dispatch]
Categories
(Core :: WebRTC: Audio/Video, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox110 | --- | disabled |
firefox111 | --- | disabled |
firefox112 | --- | disabled |
firefox113 | --- | fixed |
People
(Reporter: pehrsons, Assigned: pehrsons)
References
(Regression)
Details
(Keywords: crash, regression)
Crash Data
Attachments
(5 files)
+++ 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.
Comment 1•2 years ago
|
||
Set release status flags based on info from the regressing bug 1806605
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 3•2 years ago
|
||
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.
Assignee | ||
Comment 4•2 years ago
|
||
Comment 5•2 years ago
|
||
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.
Assignee | ||
Comment 6•2 years ago
|
||
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.
Assignee | ||
Comment 8•2 years ago
|
||
(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.
Comment 9•2 years ago
|
||
bugherder |
Assignee | ||
Comment 10•2 years ago
|
||
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.
Assignee | ||
Comment 11•2 years ago
|
||
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
Assignee | ||
Comment 12•2 years ago
|
||
Assignee | ||
Comment 13•2 years ago
|
||
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.
Assignee | ||
Comment 14•2 years ago
|
||
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.
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 15•2 years ago
|
||
Comment 16•2 years ago
|
||
bugherder |
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
Description
•