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

Status: RESOLVED WORKSFORME

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

Description

[Marcia Knous [:marcia]]

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:

• https://www.di.fm/synthwave
• https://meet.google.com

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 

Comment 1

[Paul Adenot (:padenot)]

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

Comment 2

[C.M.Chang[:chunmin]]

These two reports give clear crash stacks:

• https://crash-stats.mozilla.org/report/index/9e6950f6-39d6-4e17-98b5-e238a0191104
• https://crash-stats.mozilla.org/report/index/531d3443-f731-42ab-829f-d06ad0191105

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.

Comment 3

[Paul Adenot (:padenot)]

The address is zero, which is a bit fishy.

Comment 4

[Pascal Chevrel:pascalc (PTO until April 26)]

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

Comment 5

[C.M.Chang[:chunmin]]

(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.

Comment 6

[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 7

[C.M.Chang[:chunmin]]

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.