Firefox crashes when sharing screen to video calls in Fedora 35
Categories
(Core :: WebRTC, defect)
Tracking
()
People
(Reporter: unt, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:96.0) Gecko/20100101 Firefox/96.0
Steps to reproduce:
- Enter a video call (Google Meet or BigBlueButton)
- Start sharing entire screen
Actual results:
- Screen sharing might work for a few seconds
- Then it crashes (Firefox abruptly closes all opened windows and tabs)
- No error information is given
Expected results:
- Screen sharing works
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::WebRTC' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 2•3 years ago
|
||
unt, thanks for filing this. Are you using the version of Firefox that is bundled with Fedora, or have you installed it from elsewhere? Could you confirm that this still happens on Firefox Nightly? It is available here https://www.mozilla.org/en-US/firefox/all/#product-desktop-release .
(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #2)
unt, thanks for filing this. Are you using the version of Firefox that is bundled with Fedora, or have you installed it from elsewhere? Could you confirm that this still happens on Firefox Nightly? It is available here https://www.mozilla.org/en-US/firefox/all/#product-desktop-release .
Hey, so yes I use the Firefox from official Fedora repositories. I will be testing it on FIrefox Nightly, however I am thinking this bug is also related to WirePlumber and other components other than firefox...
I can also confirm this error happens in Firefox Nightly. I get the following output when the error occurs if I use firefox from terminal:
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
Exiting due to channel error.
[1] 7477 cpu limit exceeded (core dumped) ./firefox
Comment 5•3 years ago
|
||
I'm not seeing this stack on crash-stats, so this may be an isolated case. The crash stack contains code that was modified in bug 1738946; maybe that's a hint?
Comment 6•3 years ago
|
||
Could you try running mozregression (which can be installed with pip) to cover the following range?
mozregression --good=2021-11-09 --bad=2021-11-11
That should tell us whether this regressed with bug 1738946.
If both of those revisions are broken, this might be a regression from bug 1654112. To check that possibility, you could run
mozregression --good=2021-10-31 --bad=2021-11-02
If, on the other hand, both of those revisions are fine, I do not have a hypothesis for when this problem originated, and we'll probably need to significantly widen our search.
I am using Firefox on Fedora 35 and am also seeing what I take to be the same bug. I have a dual-screen (laptop + external monitor) if that helps. Firefox is stock build provided by Fedora (v 97.0). I can trigger the crash 100% reliably by starting a Google Meet call and sharing my screen. The dialog asking about which screen to share appears, I select either the internal laptop panel or the external monitor (it makes no difference), Firefox then hangs (video freezes) for about 5 seconds then core dumps. ``` ```
I am using Firefox on Fedora 35 and am also seeing what I take to be the same bug. I have a dual-screen (laptop + external monitor) if that helps.
Firefox is stock build provided by Fedora (v 97.0).
I can trigger the crash 100% reliably by starting a Google Meet call and sharing my screen. The dialog asking about which screen to share appears, I select either the internal laptop panel or the external monitor (it makes no difference), Firefox then hangs (video freezes) for about 5 seconds then core dumps.
Reporter | ||
Comment 10•3 years ago
|
||
(In reply to Byron Campen [:bwc] from comment #6)
Could you try running mozregression (which can be installed with pip) to cover the following range?
mozregression --good=2021-11-09 --bad=2021-11-11
That should tell us whether this regressed with bug 1738946.
If both of those revisions are broken, this might be a regression from bug 1654112. To check that possibility, you could run
mozregression --good=2021-10-31 --bad=2021-11-02
If, on the other hand, both of those revisions are fine, I do not have a hypothesis for when this problem originated, and we'll probably need to significantly widen our search.
The mozregression commands are not doing it for me. They are crashing. Is there something speacial I should be doing? I tried installing with and without sudo, but the errors are the same (python errors).
(In reply to donald_i from comment #9)
I am using Firefox on Fedora 35 and am also seeing what I take to be the same bug. I have a dual-screen (laptop + external monitor) if that helps.
Firefox is stock build provided by Fedora (v 97.0).
I can trigger the crash 100% reliably by starting a Google Meet call and sharing my screen. The dialog asking about which screen to share appears, I select either the internal laptop panel or the external monitor (it makes no difference), Firefox then hangs (video freezes) for about 5 seconds then core dumps.
By the way, I am also using an external monitor with my laptop. It seems me and donald_i have similar setups and the same problem.
Comment 11•3 years ago
|
||
The severity field is not set for this bug.
:mjf, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 12•3 years ago
|
||
unt, as an additional data point, have you tried screen sharing with only one screen (no external monitor attached)?
If you wouldn't mind, please attach the crashing output for mozregression. Someone might be able to help if we can see the output.
Comment 13•3 years ago
|
||
Marking confirmed since donald_i's additional report.
Comment 14•3 years ago
|
||
I am experiencing the same issue on stock Firefox 98 on Fedora 35. It used to work with Firefox 96, crashes reproducably since I've upgraded to Firefox 97 a few weeks ago.
I'm running Wayland with Sway window manager, laptop screen only.
Comment 15•3 years ago
|
||
Cross reference to Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2059998
Comment 16•3 years ago
|
||
From the Fedora bug report, it appears to be something that landed between firefox-97.0-1.fc35.x86_64 and firefox-97.0.1-2.fc35.x86_64.
Stefan, if you could run mozregression that would be extremely helpful.
Comment 17•3 years ago
|
||
(In reply to Michael Froman [:mjf] from comment #16)
From the Fedora bug report, it appears to be something that landed between firefox-97.0-1.fc35.x86_64 and firefox-97.0.1-2.fc35.x86_64.
Stefan, if you could run mozregression that would be extremely helpful.
Michael, I did run mozregression --good 96 --bad 98
to no avail. It didn't identify any bad build at all, ie. screensharing worked in all test builds.
I evaluated a few Fedora Firefox releases. While firefox-97.0.1-1.fc35.x86_64 does work well, firefox-97.0.1-2.fc35.x86_64 does not. So, it looks like the bug was introduced in firefox-97.0.1-2.fc35.x86_64.
Comment 18•3 years ago
|
||
Stefan, thank you for taking the time to do that. Sorry it didn't give us more data.
bwc: could this be something specific to the fedora version?
Comment 19•3 years ago
|
||
I'm also affected by this, also running sway on a single monitor. Downgrading to Firefox-97.0.1-1.fc35.x86_64 fixes the issues for me as well.
Comment 20•3 years ago
|
||
(In reply to Michael Froman [:mjf] from comment #18)
Stefan, thank you for taking the time to do that. Sorry it didn't give us more data.
No worries!
bwc: could this be something specific to the fedora version?
Well, that's a question the Fedora package maintainers maybe are able to answer. I documented my findings in the Fedora ticket (https://bugzilla.redhat.com/show_bug.cgi?id=2059998) as well, and am hoping it gets some attention.
Comment 21•3 years ago
|
||
(In reply to Michael Froman [:mjf] from comment #18)
Stefan, thank you for taking the time to do that. Sorry it didn't give us more data.
bwc: could this be something specific to the fedora version?
(In reply to Stefan Hübner from comment #14)
I am experiencing the same issue on stock Firefox 98 on Fedora 35. It used to work with Firefox 96, crashes reproducably since I've upgraded to Firefox 97 a few weeks ago.
I'm running Wayland with Sway window manager, laptop screen only.
(In reply to sannnagy from comment #19)
I'm also affected by this, also running sway on a single monitor. Downgrading to Firefox-97.0.1-1.fc35.x86_64 fixes the issues for me as well.
Maybe this is a wayland bug? Are you running wayland as well?
Updated•3 years ago
|
Comment 23•3 years ago
|
||
Maybe this is a wayland bug? Are you running wayland as well?
Yes I'm running wayland. After testing this further, screenshare is working fine for me on gnome wayland session but crashes while using sway. Can anyone else confirm they have the same experience? If that's the case, this could be a bug related to sway/xdg-desktop-portal-wlr/wlroots.
Comment 24•3 years ago
|
||
(In reply to sannnagy from comment #23)
Maybe this is a wayland bug? Are you running wayland as well?
Yes I'm running wayland. After testing this further, screenshare is working fine for me on gnome wayland session but crashes while using sway. Can anyone else confirm they have the same experience? If that's the case, this could be a bug related to sway/xdg-desktop-portal-wlr/wlroots.
I've checked both firefox-97.0.1-1.fc35.x86_64 and firefox-97.0.1-2.fc35.x86_64 in a GNOME Wayland session.
Screen sharing worked fine in firefox-97.0.1-1.fc35.x86_64. firefox-97.0.1-2.fc35.x86_64 crashed.
Comment 25•2 years ago
|
||
I've skipped a couple of release updates and gave firefox-102.0-1.fc35.x86_64 a try. The bug is no longer reproducible.
Comment 26•2 years ago
|
||
Redirect a needinfo that is pending on an inactive user to the triage owner.
:mjf, since the bug has recent activity, could you have a look please?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Description
•