1635973 - Crash in [@ cubeb_resampler_speex<T>::fill_internal_duplex]

Status: RESOLVED WORKSFORME

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

Description

[C.M.Chang[:chunmin]]

This bug is for crash report 503a9702-6d19-4809-96a5-b32770200504. It's macos-only.

Top 5 frames of crashing thread:
0 libsystem_platform.dylib _platform_memmove$VARIANT$Haswell
1 XUL cubeb_resampler_speex<float, cubeb_resampler_speex_one_way<float>, delay_line<float> >::fill_internal_duplex(float*, long*, float*, long) media/libcubeb/src/cubeb_resampler.cpp:288
2 XUL cubeb_coreaudio::backend::audiounit_output_callback media/libcubeb/src/cubeb_resampler.cpp:374
3 libsystem_c.dylib _vsnprintf
4 CoreAudio typeinfo name for std::bad_alloc

Comment 1

[C.M.Chang[:chunmin]]

I am dealing with a problem that could have a very similar crash-signature today, so I go to crash reports to check if Firefox users encountered the one I find. That problem was introduced when fixing bug 1629839 which was landed in FF 76.

The good news is, this crash stops in Firefox 76, so the patches for bug 1629839 harm nothing in real world.

The problem I find today has similar stack of the crashes here. It hits an assertion after calling input_processor->input in cubeb_resampler_speex<T>::fill_internal_duplex. However, this crash-signature appeared before switching our audio backend to Rust version (503a9702-6d19-4809-96a5-b32770200504), so we might have this kind of crash for a long time. It starts from at least FF 73. Therefore that this crash was caused by different scenarios. Maybe at the end of every scenarios, they all hit the same assertion. I don't know.

This bug is open for tracking if this happens again. If there is no more crash after FF 77, I will close it.

Comment 2

[C.M.Chang[:chunmin]]

No crash in the latest Firefox and one possible cause is fixed and imported into gecko.