Closed Bug 1595457 Opened 3 years ago Closed 2 years ago

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


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






(Reporter: gsvelto, Assigned: chunmin)


(Blocks 1 open bug)


(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/
2 XUL std::panicking::rust_panic_with_hook src/libstd/
3 XUL std::panicking::begin_panic src/libstd/
4 XUL coreaudio_sys_utils::dispatch::create_closure_and_executor::closure_executer media/libcubeb/cubeb-coreaudio-rs/coreaudio-sys-utils/src/
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()

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
Depends on: 1614389

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

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

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