1595457 - Crash in [@ coreaudio_sys_utils::dispatch::create_closure_and_executor::closure_executer]

Status: RESOLVED WORKSFORME

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

Description

[Gabriele Svelto [:gsvelto]]

This bug is for crash report bp-bb120d14-8edd-482b-94de-9eae20191109.

Top 10 frames of crashing thread:

0 XUL gkrust_shared::panic_hook mfbt/Assertions.h:332
1 XUL core::ops::function::Fn::call src/libcore/ops/function.rs:69
2 XUL std::panicking::rust_panic_with_hook src/libstd/panicking.rs:481
3 XUL std::panicking::begin_panic src/libstd/panicking.rs:411
4 XUL coreaudio_sys_utils::dispatch::create_closure_and_executor::closure_executer media/libcubeb/cubeb-coreaudio-rs/coreaudio-sys-utils/src/dispatch.rs:59
5  @0x7fff6644cdb7 
6  @0x7fff66461216 
7  @0x7fff66454165 
8  @0x7fff66461f0c 
9  @0x7fff66465d20 

The raw crash reason is !self.core_stream_data.input_unit.is_null() || !self.core_stream_data.output_unit.is_null()

https://searchfox.org/mozilla-central/source/media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs#3243-3246

Comment 1

[C.M.Chang[:chunmin]]

I don't know the reason why the assertion is hit.

1. reinit can be called, so one of self.core_stream_data.input_unit and self.core_stream_data.output_unit is not null when the cubeb stream was initialized. Otherwise reinit_async wouldn't be fired in audiounit_input_callback or audiounit_property_listener_callback. audiounit_input_callback would be fire when self.core_stream_data.input_unit is not null. audiounit_property_listener_callback would be fired when one or both of self.core_stream_data.input_unit and self.core_stream_data.output_unit are set.

2. Since !self.core_stream_data.input_unit.is_null() || !self.core_stream_data.output_unit.is_null() was true at first (by 1), hitting that assertion means the CoreStreamData::close was called before the assertion is hit. self.core_stream_data.input_unit and self.core_stream_data.output_unit would only be reset to null in CoreStreamData::close.

3. The CoreStreamData::close can be fired from two places

   • destroy, when the cubeb stream is being destroyed
   • reinit, when the cubeb stream fails being reinitialized (failing in previous reinit)

4. If close is from destroy:

   • destroy_pending would be true before close is called.
   • If destroy_pending is true, then reinit wouldn't be executed.
   • In addition, destroy_internal and reinit would be run in the same task queue
   • By above, reinit wouldn't be executed after destroy is called, so the assertion won't be hit if destroy task was executed.

5. If close is from reinit:

   • the audiounit_property_listener_callback would be unregistered by uninstall_device_changed_callback and uninstall_system_changed_callback. That is, reinit wouldn't be called from audiounit_property_listener_callback anymore when devices are changed.
   • The active AudioUnit would be stopped in reinit at first, and wouldn't be started again since stream reinitializarion fails, so audiounit_input_callback wouldn't be called if reinit fails. So reinit_async wouldn't be fired in audiounit_input_callback if reinit fails.
   • By above, if reinit fails, then reinit wouldn't be called again, so the assertion won't be hit if previous reinit failed.

The above analysis is based on the code flow that should be run. Maybe the task dispatcher doesn't work in an expected way so something went wrong. I have no idea now.

Comment 2

[C.M.Chang[:chunmin]]

There is a UAF found in cubeb-coreaudio-rs #48, which is possibly caused by doing stream-reinitialization after the stream is being destroyed.

Comment 3

[C.M.Chang[:chunmin]]

No more crash in one month. Feel free to reopen it if the problem reappears.