1806521 - Crash in [@ webrtc::videocapturemodule::VideoCaptureImpl::DeliverCapturedFrame]

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

Crash report: https://crash-stats.mozilla.org/report/index/6eb9de73-4b94-47c3-8b66-9ad3b0221219

Reason: EXC_BAD_ACCESS / EXC_I386_GPFLT

Top 10 frames of crashing thread:

0  XUL  webrtc::videocapturemodule::VideoCaptureImpl::DeliverCapturedFrame  third_party/libwebrtc/modules/video_capture/video_capture_impl.cc:120
1  XUL  webrtc::videocapturemodule::VideoCaptureAvFoundation::OnFrame  dom/media/systemservices/objc_video_capture/video_capture_avfoundation.mm:168
2  XUL  -[VideoCaptureAdapter capturer:didCaptureVideoFrame:]  dom/media/systemservices/objc_video_capture/video_capture_avfoundation.mm:89
3  XUL  -[RTCCameraVideoCapturer captureOutput:didOutputSampleBuffer:fromConnection:]  third_party/libwebrtc/sdk/objc/components/capturer/RTCCameraVideoCapturer.m:299
4  AVFoundation  __49-[AVCaptureVideoDataOutput _render:sampleBuffer:]_block_invoke  
5  libdispatch.dylib  _dispatch_call_block_and_release  
6  libdispatch.dylib  _dispatch_client_callout  
7  libdispatch.dylib  _dispatch_lane_serial_drain  
8  libdispatch.dylib  _dispatch_lane_invoke  
9  libdispatch.dylib  _dispatch_workloop_worker_thread  

Comment 1

[Jeff Muizelaar [:jrmuizel]]

"Hi folks, I just encountered a (for me) reproducible crash
https://crash-stats.mozilla.org/report/index/5c8a444d-ad92-4952-abc9-3c1eb0221219 and
https://crash-stats.mozilla.org/report/index/0215dfe5-923e-4444-9a10-823270221219

Basically Firefox appears to crash whenever I close a tab with a local video feed rendered in it.

So basically just sit in on the lobby room (after you approved the cam/mic access) and before even clicking the "join" button. Close the browser window and all of Firefox crashes for me."

Comment 2

[Jeff Muizelaar [:jrmuizel]]

karlt writes https://crash-stats.mozilla.org/search/?signature=~webrtc%3A%3Avideocapturemodule%3A%3AVideoCaptureImpl%3A%3ADeliverCapturedFrame&date=%3E%3D2022-12-01T21%3A50%3A00.000Z&date=%3C2022-12-19T21%3A50%3A00.000Z&_facets=signature&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports seems to point at https://bugzilla.mozilla.org/show_bug.cgi?id=1451394

Comment 3

[Karl Tomlinson (:karlt)]

Could this be bug 1621500 back again?

Comment 4

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: sec-high reproducible crash regression

Comment 5

[Andreas Pehrson [:pehrsons]]

FWIW the new camera backend causing this is only enabled in nightly and early beta. I'll disable it everywhere until we've fixed this.

Comment 6

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1806521 - Disable new mac camera backend. r?karlt!

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Disable new mac camera backend. r=karlt
https://hg.mozilla.org/integration/autoland/rev/8cceecf2808be894589d0d05c31934114b6a65d2
https://hg.mozilla.org/mozilla-central/rev/8cceecf2808b

Comment 10

[Brindusa Tot, Desktop QA]

Jeff, is this easy reproducible? Could we manually verify this issues? If yes, could you please help us with reproduction steps?

Comment 11

[Andreas Pehrson [:pehrsons]]

Yes, it should be easily reproducible.
STR:

1. With two tabs, open gum_test in one of them
2. Start the camera so that it is capturing
3. Close the current tab

Expected: Tab closes, camera stops capturing
Actual: Parent process crash

Comment 12

[Ciprian Georgiu, Desktop QA]

Unfortunately, I'm unable to reproduce the crash with the steps mentioned above. I've tried on several different macOS versions (10.14, 10.15, 11 and 12), with an affected Nightly build (2022-12-19).

Jeff Muizelaar, since the crash does not reproduce on my end, could you please help us verify this bug on latest Nightly 110.0a1?