By the crash reports, the MOZ_CRASH Reason (Sanitized) is register default_output_listener without unregistering the one in use. That means the assertion: https://github.com/mozilla/cubeb-coreaudio-rs/blob/5a5bc63d7ee37ea78adfa7c958d45b1595bf6c61/src/backend/mod.rs#L2984-L2987
in install_system_changed_callback is hit. The thread hitting the assertion is on coreaudio_sys_utils::dispatch::Queue::create_closure_and_executor::closure_executer so this crash is very likely to happen when running reinit (the stream is being reinitializing).
This should solve the crash on BMO 1708718.
By the crash reports, the MOZ_CRASH Reason (Sanitized) is
register default_output_listener without unregistering the one in use. That means the assertion: https://github.com/mozilla/cubeb-coreaudio-rs/blob/5a5bc63d7ee37ea78adfa7c958d45b1595bf6c61/src/backend/mod.rs#L2984-L2987 ininstall_system_changed_callbackis hit. The thread hitting the assertion is oncoreaudio_sys_utils::dispatch::Queue::create_closure_and_executor::closure_executerso this crash is very likely to happen when runningreinit(the stream is being reinitializing).I managed to reproduce the crash by the comment here. If
default_input_listenerfails to be registered in the firstsetup: https://github.com/mozilla/cubeb-coreaudio-rs/blob/5a5bc63d7ee37ea78adfa7c958d45b1595bf6c61/src/backend/mod.rs#L3297 thendefault_output_listeneris aSomewhen the secondsetupis called: https://github.com/mozilla/cubeb-coreaudio-rs/blob/5a5bc63d7ee37ea78adfa7c958d45b1595bf6c61/src/backend/mod.rs#L3312 and it ends up hitting the assertion sincedefault_output_listeneris not aNone