Closed Bug 1559433 Opened 5 years ago Closed 5 years ago

[10.15] Crash in [@ libsystem_kernel.dylib@0x76ce]

Categories

(Core :: WebRTC, defect, P2)

Unspecified
macOS
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr68 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix

People

(Reporter: marcia, Assigned: dminor)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

This bug is for crash report bp-895976f6-4a6f-471d-a66c-9c5950190614.

Seen while looking at nightly crash stats: https://bit.ly/2WFRnMy. 76 crashes across all versions, but more in nightly 69 than the other branches. A quick scan of the crashes shows not all of them are crashing in the same area. We will probably have to break them out by proto signature, but this particular one has some webrtc and mozilla:camera stuff in it.

17 XUL +[DeviceInfoIosObjC captureDeviceCount] media/webrtc/trunk/webrtc/modules/video_capture/objc/device_info_objc.mm:46 frame_pointer
18 XUL webrtc::videocapturemodule::DeviceInfoIos::Init() media/webrtc/trunk/webrtc/modules/video_capture/objc/device_info.mm:54 frame_pointer
19 XUL webrtc::videocapturemodule::VideoCaptureImpl::CreateDeviceInfo() media/webrtc/trunk/webrtc/modules/video_capture/objc/device_info.mm:38 frame_pointer
20 XUL mozilla::camera::VideoEngine::GetOrCreateVideoCaptureDeviceInfo() dom/media/systemservices/VideoEngine.cpp:182 frame_pointer
21 XUL mozilla::camera::CamerasParent::EnsureInitialized(int) dom/media/systemservices/CamerasParent.cpp:420 frame_pointer

Some URLs:

*https://voice.google.com/calls
*https://meet.google.com/_meet

Top 10 frames of crashing thread:

0 libsystem_kernel.dylib libsystem_kernel.dylib@0x76ce 
1 libsystem_c.dylib libsystem_c.dylib@0x7f91b 
2 libsystem_c.dylib libsystem_c.dylib@0x7ebd5 
3 CoreMediaIO CoreMediaIO@0x8d83 
4 CoreMediaIO CoreMediaIO@0xa6b2 
5 AVFoundation AVFoundation@0x1324f6 
6 AVFoundation AVFoundation@0x131f04 
7 AVFoundation AVFoundation@0x131d95 
8 AVFoundation AVFoundation@0x30fde 
9 AVFoundation AVFoundation@0x30ca6 

Assignee: nobody → dminor
Blocks: catalina

The crash is occurring here: [1]. As far as I can tell, the code is correct as written, the call to AVCaptureDevice devicesWithMediaType: should return a NSArray containing the devices available on the system. It might be empty, but there is nothing in the documentation [2] to suggest that a null pointer would be returned rather than an empty array.

This function is marked deprecated, the replacement is discoverySessionWithDeviceTypes [3] which is only available on 10.15. Since this code was changed in 10.15, which is currently in Beta, the most likely explanation to me is that devicesWithMediaType was accidentally broken while Apple was implementing discoverSessionWithDeviceTypes and it will likely be fixed by the time 10.15 is released.

As a workaround, we could add a check for a null pointer being returned by devicesWithMediaType, but that really shouldn't be necessary. If the crash volume remains low, I think it makes sense to monitor the crash stats to see if this is fixed on Apple's side before we change the code here. It is in webrtc.org, which is third-party code, so there is a maintenance burden associated with making changes to it.

[1] https://hg.mozilla.org/mozilla-central/annotate/19cf79b6f07d4c5c93d29d6b73d40df4497db657/media/webrtc/trunk/webrtc/modules/video_capture/objc/device_info_objc.mm#l46
[2] https://developer.apple.com/documentation/avfoundation/avcapturedevice/1390520-devices
[3] https://developer.apple.com/documentation/avfoundation/avcapturedevicediscoverysession/2361539-discoverysessionwithdevicetypes?language=objc

Priority: -- → P2

Adding another signature with similar stuff in the stack. Some comments:

*Google Meet/Hangouts crash every time on macOS 10.15 Catalina beta

  • Always… AliPay confirmation
Crash Signature: [@ libsystem_kernel.dylib@0x76ce] → [@ libsystem_kernel.dylib@0x76ce] [@ libsystem_kernel.dylib@0x75be]

these crash signatures seem to have faded in the meantime - i think it wasn't a mere signature shift either, since i couldn't spot any other major stability issue with webrtc on the stack for current nightly users on macos 10.15 beta.
therefore i'll close the report.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.