You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I've discovered a bug where the stream's data callback gets called even after alsa_stream_stop has been called. This in-turn causes a crash in Firefox when it tries to capture the microphone from it's WebRTC component (happens very rarely). I've traced it down to cubeb. This does not seem to be reproducible with the example program from the docs
Still debugging it, will keep updating here with more details
I haven't verified this, but do you think there's a possibility that the calls to alsa_set_stream_state in alsa_stream_stop and alsa_run could be "racing" due to interleaved calls to mutex locks and unlocks?
So even tho the calls are wrapped in mutexes, it might happen that alsa_stream_stop sets the state to INACTIVE, and it subsequently gets set to PROCESSING by the other thread after that thread locks the mutex
Hello, I've discovered a bug where the stream's data callback gets called even after
alsa_stream_stop
has been called. This in-turn causes a crash in Firefox when it tries to capture the microphone from it's WebRTC component (happens very rarely). I've traced it down to cubeb. This does not seem to be reproducible with the example program from the docsStill debugging it, will keep updating here with more details
More details: https://bugzilla.mozilla.org/show_bug.cgi?id=1859796
The text was updated successfully, but these errors were encountered: