Closed Bug 1753410 Opened 3 years ago Closed 2 years ago

Firefox crashes when sharing screen to video calls in Fedora 35

Categories

(Core :: WebRTC, defect)

Product:
Core
Component:
WebRTC
Version:
Firefox 96
Type:
defect

Tracking

()

Status:
RESOLVED INACTIVE

People

(Reporter: unt, Unassigned)

References

Details

Attachments

(2 files)

journal_logs.txt
34.53 KB, text/plain
Details
journalctl log of crash
114.17 KB, text/plain
Details
Attached file journal_logs.txt —

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

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.

Component: Untriaged → WebRTC
Product: Firefox → Core

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 .

Flags: needinfo?(unt)

(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...

Flags: needinfo?(unt)

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

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?

See Also: → 1738946

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.

^

Flags: needinfo?(unt)
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.

(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.

Flags: needinfo?(unt)

The severity field is not set for this bug.
:mjf, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(mfroman)

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.

Flags: needinfo?(mfroman) → needinfo?(unt)

Marking confirmed since donald_i's additional report.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

Cross reference to Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2059998

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.

Flags: needinfo?(sthuebner)

(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.

Flags: needinfo?(sthuebner)

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?

Flags: needinfo?(docfaraday)

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.

(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.

(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?

Flags: needinfo?(docfaraday)
Flags: needinfo?(unt)

^

Flags: needinfo?(unt)

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.

(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.

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.

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.

Flags: needinfo?(unt) → needinfo?(mfroman)
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(mfroman)
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: