Closed Bug 1830533 Opened 2 years ago Closed 2 years ago

[VM Ubuntu 22.1] System freezes when sharing screen on a Zoom meeting

Categories

(Core :: WebRTC: Audio/Video, defect)

Desktop
Linux
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr102 --- unaffected
firefox112 --- wontfix
firefox113 --- wontfix
firefox114 --- wontfix

People

(Reporter: atrif, Unassigned)

Details

(Keywords: regression, regressionwindow-wanted)

Found in

  • 114.0a1 (2023-04-27)

Affected versions

  • 114.0a1 (2023-04-27)
  • 113.0b9
  • 112.0.2

Tested platforms

  • Affected platforms: Ubuntu 22.1
  • Unaffected platforms: Windows 10x64, macOS 12,

Steps to reproduce

  1. Join a Zoom meeting and share the entire screen.

Expected result

  • Firefox and the operating system are working as expected.

Actual result

  • Firefox and the operating system freeze after a couple of seconds.

Regression range

  • I cannot reproduce this with Firefox 102.10.0esr but I can with RC 111.0. I will search for one ASAP if there is one.

Additional notes

  • Unfortunately I only have this installed inside a VM. It may be a VM problem.
QA Whiteboard: [qa-regression-triage]

If you can get a crash report from this state that would help too. I think you can get one by sending SIGABRT to the parent process.

(In reply to Andreas Pehrson [:pehrsons] from comment #1)

If you can get a crash report from this state that would help too. I think you can get one by sending SIGABRT to the parent process.

Hello is there documentation or some steps on how to do that? Thank you in advance!

Flags: needinfo?(apehrson)

You can see the parent process id in about:processes at the top where it says Nightly (NNNNN). NNNNN is the process id, PID.

Send it SIGABRT in a terminal by kill -SIGABRT NNNNN. Note this is meant for linux.

Flags: needinfo?(apehrson)

(In reply to Andreas Pehrson [:pehrsons] from comment #3)

You can see the parent process id in about:processes at the top where it says Nightly (NNNNN). NNNNN is the process id, PID.

Send it SIGABRT in a terminal by kill -SIGABRT NNNNN. Note this is meant for linux.

Unfortunately, I cannot do this because the whole linux system freezes not only Firefox and I can't do anything after that only shut down or REISUB. No crashes are recorded inside about:crashes after restart.

Are terminals through tty3 and ssh (if you connect before the hang) unavailable as well?

I got this crash report when I opened my VM today: https://crash-stats.mozilla.org/report/index/e11593e5-bf43-4fc0-9da0-848450230504. May this be related? I don't know if this is from the hang...
Maybe this was because I used kill -SIGABRT NNNNN inside the terminal before I reproduced the hang?

Plausible, but I'd need a crash report for the parent process (where video capture happens) to be able to make sense of it.

I've attempted reproduction on a non-VM system and no freeze or crash could be reproduced.
Considering the fact that this issue was not caught by the recurrent WebRTC testing in the last 4 months, I think we can safely say that this issue might be caused by testing in a VM or that it's a somewhat special edge case.

Furthermore, considering that the crash report requested in comment 1 cannot be obtained, I am closing with the status WORKSFORME.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.