whole Firefox stuck/hanging
Categories
(Core :: Widget: Win32, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox99 | --- | fixed |
People
(Reporter: aryx, Unassigned)
References
(Regression)
Details
Firefox 99.0a1 20220216094238 on Windows 8.1, Firefox 32-bit build
After it had been running for maybe 20 minutes, Firefox got unresponsive and didn't recover. There was a conversation in Slack ongoing while this happened and I tried to click in there while a desktop notification might have been triggered, not sure if this is relevant.
Loading the full dump into VS focuses on https://searchfox.org/mozilla-central/rev/3de1b6791ea569cdf7773f7cd512cf2e6cc1d3f0/third_party/rust/audioipc2/src/ipccore.rs#115-118 as the next statement to execute when the thread returns from the current function. Related to https://hg.mozilla.org/mozilla-central/rev/e1b946a41694ac09bdf123d5aa7b9bc16f18449d / bug 1617283? Could you take a look?
Attempts to reproduce the issue have failed so far but bug 1755700 has been reported as regression from that change.
Comment 1•3 years ago
|
||
We'll take a look. Bug 1617283 can be backed out if we don't find it quickly.
Comment 2•3 years ago
|
||
FWIW, AudioSession is for integration with the sound mixer in the Windows dock. It's not related to playing audio, or audioipc2. So this may be unrelated to bug 1617283 but I want to try to check if it's related through some mutual behavior here.
| Reporter | ||
Comment 3•3 years ago
|
||
This issue had been observed a second time with the same build yesterday. Since updating Nightly later that day, it has not reproduced anymore.
Comment 4•3 years ago
|
||
We've discovered one way to reproduce the crash or unresponsive behavior
- Plug in an audio device and make sure its the primary playback device
- Play any video on youtube
- Unplug the audio device connected in the first step. When unplugged the video playback would be stopped, but the browser itself does not become unresponsive.
- Open any other video in another tab. As soon as this is done the browser becomes unresponsive. If it does not, changing active tab to the newly opened one surely does.
As you've mentioned in your comment, this is ONLY reproducible with the patch for bug 1617283 applied and not without the patch. So it is safe to assume the issue is in the changeset introduced by that patch. (We're looking into what exactly is causing this.)
This only happens when the playback device, that was primary device when firefox was launched, is unplugged. Removing any other audio device than the one in use does not lead to unresponsive behaviour or the video playback interrupting. Tested individually on headset connected to a USB 3.0 port and the 3.5mm audio jack. Both crash the browser.
Also, there is no claim that this is reproducible only on video playback on youtube. I have only been able to crash firefox aforementioned steps using youtube (maybe due to resource intensiveness). Unplugging the primary playback device while playing an mp3 file does lead to disruption in audio playback of said file but does not crash the browser even after opening other tabs (once again this maybe due to resource intensiveness).
Lastly, I'm not sure if there are any other ways to crash the browser with the patch applied. The aforementioned steps are just the way that has been discovered yet.
Comment 5•3 years ago
|
||
The severity field is not set for this bug.
:spohl, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 6•3 years ago
|
||
Fixed by backout of bug 1617283 (see bug 1617283 comment 11).
Description
•