1658982 - Crash in [@ core::ptr::drop_in_place | cubeb_coreaudio::backend::aggregate_device::AggregateDevice::new]

Status: RESOLVED FIXED

(Core :: Audio/Video: cubeb, defect, P1)

Description

[Sean Feng [:sefeng]]

This bug is for crash report bp-73d72a09-b11e-4385-943e-f8b600200811.

Top 10 frames of crashing thread:

0 XUL RustMozCrash mozglue/static/rust/wrappers.cpp:17
1 XUL mozglue_static::panic_hook mozglue/static/rust/lib.rs:89
2 XUL core::ops::function::Fn::call src/libcore/ops/function.rs:72
3 XUL std::panicking::rust_panic_with_hook src/libstd/panicking.rs:474
4 XUL rust_begin_unwind src/libstd/panicking.rs:378
5 XUL std::panicking::begin_panic_fmt src/libstd/panicking.rs:332
6 XUL core::ptr::drop_in_place src/libcore/ptr/mod.rs:177
7 XUL cubeb_coreaudio::backend::aggregate_device::AggregateDevice::new third_party/rust/cubeb-coreaudio/src/backend/aggregate_device.rs:39
8 XUL cubeb_coreaudio::backend::CoreStreamData::setup third_party/rust/cubeb-coreaudio/src/backend/mod.rs:2464
9 XUL <cubeb_coreaudio::backend::AudioUnitContext as cubeb_backend::traits::ContextOps>::stream_init third_party/rust/cubeb-coreaudio/src/backend/mod.rs:2220

This is MacOS only and occurred in various installations. Looks like we are dereferencing a null pointer somewhere.

Comment 1

[Matthew Gregan [:kinetik]]

Failing with the below assert, likely from audio_object_add_property_listener or audio_object_remove_property_listener in set_sub_devices_sync.

assertion failed: `(left == right)`
  left: `560947818`,
  right: `0`

560947818 is kAudioHardwareBadObjectError.

:chunmin, any ideas?

Comment 2

[C.M.Chang[:chunmin]]

Not sure why audio_object_add_property_listener or audio_object_remove_property_listener returns a kAudioHardwareBadObjectError.

By the definition of kAudioHardwareBadObjectError:

The AudioObjectID passed to the function doesn't map to a valid AudioObject.

, it means the device_id we passed in audio_object_add_property_listener or audio_object_remove_property_listener is invalid AudioObject. However, it's created by AggregateDevice::create_blank_device_sync and we've confirmed it's already in the device list.

1. Maybe device-is-in-the-list is not a good indicator to know we can monitor the sub-devices now. If that's the case, we should get the error when audio_object_add_property_listener (If audio_object_remove_property_listener returns kAudioHardwareBadObjectError, then it means the device_id is not still not valid yet. It implies the device_id is also not valid yet when audio_object_add_property_listener is called.)
2. Or maybe the audio_object_remove_property_listener could return the kAudioHardwareBadObjectError if one of the sub-device is destroyed. This requires some additional hardwares to test but all my devices are locked in the office.

I can replace the assertion by returning an error to see if 1 is the case. The AggregateDevice::set_sub_devices_sync returns a std::result::Result anyway.

Comment 3

[C.M.Chang[:chunmin]]

Attachment: GitHub Pull Request

Comment 4

[C.M.Chang[:chunmin]]

Attachment: Bug 1658982 - P1: Update cubeb-coreaudio to 91a7bb5

Comment 5

[C.M.Chang[:chunmin]]

Attachment: Bug 1658982 - P2: mach vendor rust

Depends on D87618

Comment 6

[C.M.Chang[:chunmin]]

Mark leave-open for now to see if the crash stops.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bd4151c7acef
P1: Update cubeb-coreaudio to 91a7bb5 r=cubeb-reviewers,kinetik
https://hg.mozilla.org/integration/autoland/rev/8d5f33309c25
P2: mach vendor rust r=cubeb-reviewers,kinetik

Comment 8

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/bd4151c7acef
https://hg.mozilla.org/mozilla-central/rev/8d5f33309c25

Comment 9

[C.M.Chang[:chunmin]]

From the report here, the crash still exists

assertion failed: `(left == right)`
  left: `560947818`,
 right: `0`

It seems the code fails here, instead of the try-to-fix patch here.

The 560947818 is actually kAudioHardwareBadObjectError. It's weird that the same device device_id works for audio_object_add_property_listener but fails at audio_object_remove_property_listener.

If the error is kAudioHardwareBadObjectError, that (aggreagte) device is probably dead at that time, maybe we should bail out in that case.

Comment 10

[C.M.Chang[:chunmin]]

Attachment: GitHub Pull Request

Comment 11

[C.M.Chang[:chunmin]]

Attachment 9181428 [details] will be landed via bug 1672459