Bug 1635973 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I am dealing with [a problem][ISS91] 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][ISS91] was introduced when fixing bug 1629839 which was landed in *FF 76*. 

The good news is, this crash [stops in Firefox 75](https://crash-stats.mozilla.org/signature/?signature=_platform_memmove%24VARIANT%24Haswell%20%7C%20cubeb_resampler_speex%3CT%3E%3A%3Afill_internal_duplex&date=%3E%3D2020-01-01T22%3A37%3A00.000Z&date=%3C2020-05-06T22%3A37%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1), so the patches for bug 1629839 harm nothing in real world.

[The problem][ISS91]  I find today has similar stack of  the crashes here. It hits an assertion after calling [`input_processor->input`](https://searchfox.org/mozilla-central/source/media/libcubeb/src/cubeb_resampler.cpp#288) 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](https://crash-stats.mozilla.org/report/index/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.

[ISS91]: https://github.com/ChunMinChang/cubeb-coreaudio-rs/issues/91
I am dealing with [a problem][ISS91] 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][ISS91] was introduced when fixing bug 1629839 which was landed in *FF 76*. 

The good news is, this crash [stops in Firefox 76](https://crash-stats.mozilla.org/signature/?signature=_platform_memmove%24VARIANT%24Haswell%20%7C%20cubeb_resampler_speex%3CT%3E%3A%3Afill_internal_duplex&date=%3E%3D2020-01-01T22%3A37%3A00.000Z&date=%3C2020-05-06T22%3A37%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1), so the patches for bug 1629839 harm nothing in real world.

[The problem][ISS91]  I find today has similar stack of  the crashes here. It hits an assertion after calling [`input_processor->input`](https://searchfox.org/mozilla-central/source/media/libcubeb/src/cubeb_resampler.cpp#288) 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](https://crash-stats.mozilla.org/report/index/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.

[ISS91]: https://github.com/ChunMinChang/cubeb-coreaudio-rs/issues/91

Back to Bug 1635973 Comment 1