Open Bug 1595457 Opened 2 months ago Updated 2 months ago

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

Categories

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

Unspecified
macOS
defect

Tracking

()

People

(Reporter: gsvelto, Assigned: chunmin)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

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

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:

  5. If close is from reinit:

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.

Blocks: 1530713
Priority: -- → P2
See Also: → 1594426
Assignee: nobody → cchang
See Also: → 1598413
See Also: → 1599136
Depends on: 1598413
See Also: 1598413
You need to log in before you can comment on or make changes to this bug.