Closed Bug 1594426 Opened 2 years ago Closed 2 years ago

Crash in [@ cubeb_coreaudio::backend::CoreStreamData::close]

Categories

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

All
macOS
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox71 --- disabled
firefox72 --- disabled
firefox73 --- disabled

People

(Reporter: marcia, Assigned: chunmin)

References

(Blocks 1 open bug)

Details

(Keywords: crash, regression)

Crash Data

This bug is for crash report bp-95ab48dd-77c3-4704-becc-caacc0191106.

Seen while looking at nightly crash stats: https://bit.ly/2PSQErB. Small volume macOS crash which started when 71 was in nightly.

URLs:

Top 8 frames of crashing thread:

0 XUL cubeb_coreaudio::backend::CoreStreamData::close media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs:2920
1 XUL coreaudio_sys_utils::dispatch::create_closure_and_executor::closure_executer media/libcubeb/cubeb-coreaudio-rs/coreaudio-sys-utils/src/dispatch.rs:59
2  @0x7fff5b78c63c 
3  @0x7fff5b7928df 
4  @0x7fff5b793395 
5  @0x7fff5b79b6ec 
6  @0x7fff5b9cc610 
7  @0x7fff5b9cc3fc 

Assignee: nobody → cchang

Chunmin, this is crashing when destroying the resampler in your new code.

Flags: needinfo?(cchang)

These two reports give clear crash stacks:

but I have no idea what happens. These two crashes happens when the cubeb stream is destroyed, so the resampler would be destroyed by code here and here. The inner pointer of AutoRelease in Resampler that points to a resampler in use will be reset to a null pointer after destroying the currently used resampler. If the inner pointer of AutoRelease in Resampler is currently null, nothing would be released since it means there is no active resampler.

The crash reason is EXC_BAD_ACCESS, so I guess it's a Use-After-Free case. But I don't know what makes it happen. If it crashes here, it means we try destroying a resampler that has been destroyed. If the resampler has been destroyed, then the inner pointer of AutoRelease in Resampler would be set to null and Resampler::destroy wouldn't do anything....

One possible situation is that Resampler::destroy is being called at the same time within multiple threads. Resampler::destroy could be called in reinit thread when switching audio devices or in a task thread when the cubeb stream is destroyed. But these two destroying tasks would be run on the same dispatch queue...

I'll keep the needinfo for now, as a reminder to revisit this problem.

The address is zero, which is a bit fishy.

Blocks: 1530713
See Also: → 1595457

Wontfox for 71 given that we don't have crashes in beta and only a handful in nightly 72.

(In reply to Pascal Chevrel:pascalc from comment #4)

Wontfox for 71 given that we don't have crashes in beta and only a handful in nightly 72.

This only happens in our new audio backend that only turns on in Nightly now.

Flags: needinfo?(cchang)
See Also: → 1598413
Priority: -- → P2
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.

I am going to mark this fixed since this crash doesn't pop up for more than one month. Feel free to reopen if this crash emerges again.

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