Closed Bug 1549095 Opened 6 years ago Closed 5 years ago

Executing getDisplayMedia() occasionally freezes operating system except for cursor movement

Categories

(Core :: WebRTC, defect, P2)

Product:
Core
Component:
WebRTC
Version:
68 Branch
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1558475

People

(Reporter: guest271314, Unassigned)

Details

Attachments

(3 files)

getDisplayMediaFreezesOperatingSystem.html
8.05 KB, text/html
Details
Image of frozen OS (except for mouse pointer) after getDisplayMedia call
117.99 KB, image/png
Details
getDisplayMediaFreezesOperatingSystem_Again.png
149.88 KB, image/png
Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

  1. Execute navigator.mediaDevices.getDisplayMedia()
  2. Execute applyConstraints() on MediaStreamTrack

Actual results:

  1. Occasionally (more than twice) the operating system freezes with the selection for which window or application to select from the location bar displayed
  2. The cursor is capable of being moved though no native application or browser GUI application is capable of being clicked or selected
  3. Requires a hard re-boot to regain functionality

Expected results:

  1. The operating system should not be frozen when navigator.mediaDevices.getDisplayMedia() is executed

The code at the linked HTML document was tried with applyConstraints() being modified to roughly (the OS freezes during testing though the tests are essentially the same)

videoConstraints = {
  cursor: "never",
  width: 320,
  height: 240,
  aspectRatio: 1.33,
  resizeMode: "crop-and-scale"
};

if (navigator.mediaDevices.getSupportedConstraints().hasOwnProperty("viewportOffsetX")) {
  // the exact value was adjusted during tests in attempt to not record location bar
  videoConstraints.viewportOffsetX = 30; 
  videoConstraints.viewportOffsetY = 30; 
}

await videoTrack.applyConstraints(videoConstraints);

Even though navigator.mediaDevices.getSupportedConstraints() returns a JavaScript plain object with "viewportOffsetX" and "viewportOffsetY" properties defined, videoTrack.getSettings() does not apply the set constraints.

Hi,
I've tried using the provided html but i wasn't able to reproduce the bug.Please gently upload the code you've used to fiddler or similar to have a working site and be available to reproduce this behavior and reach back to us with the detailed steps (ie, are you launching the code on the console or similar?).

Kind regards

Flags: needinfo?(guest271314)
Flags: needinfo?(guest271314)

(In reply to David Sacal from comment #2)

Hi,
I've tried using the provided html but i wasn't able to reproduce the bug.Please gently upload the code you've used to fiddler or similar to have a working site and be available to reproduce this behavior and reach back to us with the detailed steps (ie, are you launching the code on the console or similar?).

Kind regards

The code used is linked at the Description. Yes, the code was run at console. See attached image.

The operating system (*nix 32 bit) was frozen again today when executing getDisplayMedia

(In reply to David Sacal from comment #2)

Hi,
I've tried using the provided html but i wasn't able to reproduce the bug.Please gently upload the code you've used to fiddler or similar to have a working site and be available to reproduce this behavior and reach back to us with the detailed steps (ie, are you launching the code on the console or similar?).

Kind regards

See above attached image of OS (*nix 32 bit) frozen again today when executing getDisplayMedia at Nightly 68. Requires hard re-boot to regain control of the computer (besides mouse pointer that cannot select anything).

Hi, i've tried to reproduce the issue with the provided steps and screenshots on Ubuntu 16.04 LTS 32 Bit but i didn't manage to do it on my end. Firefox is still responsive after loading the html file and selecting the mentioned command on the doorhanger. For instance i'm selecting webrtc as a component. Also please see Bug 1551452 since it might be related.

Regards
David

Component: Untriaged → WebRTC
Product: Firefox → Core

Hi, i've tried to reproduce the issue with the provided steps and screenshots on Ubuntu 16.04 LTS 32 Bit but i didn't manage to do it on my end.

Was not trying to reproduce the OS (18.04) freezing either occasion the bug occurred.

You are not authorized to access bug 1551452.

Nico, you've run into screen share freezes on Linux in the past. Is this the same xwindow problem you think?

Flags: needinfo?(na-g)

guest271314 thanks for filing this! Bug 1551452 was only seen in 68 and has since been fixed. It manifested as a tab crash there, but from the STRs and other factors, it might be responsible for the symptoms you're reporting as well. Are you still able to reproduce it with the latest Nightly 69 or Beta 68?

Flags: needinfo?(guest271314)

(In reply to Jan-Ivar Bruaroey [:jib] (needinfo? me) from comment #10)

guest271314 thanks for filing this! Bug 1551452 was only seen in 68 and has since been fixed. It manifested as a tab crash there, but from the STRs and other factors, it might be responsible for the symptoms you're reporting as well. Are you still able to reproduce it with the latest Nightly 69 or Beta 68?

Not a bug that am eager to reproduce, again. If the user is running a live OS requires re-installing packages and re-configuring the OS after hard re-boot; a time-consuming process and an inconvenience - though crashed the tab at Chromium multiple times when testing capturing a MediaStream using MediaRecorder at a <video> element where MediaSource (https://github.com/w3c/mediacapture-record/issues/146 ; https://github.com/guest271314/web-platform-tests/pull/4 ; https://bugs.chromium.org/p/chromium/issues/detail?id=820997 ; https://github.com/w3c/media-source/issues/190 ; https://bugs.chromium.org/p/chromium/issues/detail?id=820997 ; https://github.com/web-platform-tests/wpt/issues/15816 ; https://bugs.chromium.org/p/chromium/issues/detail?id=820489) several times, evidently for no purpose as the bug is still not fixed; for equality will crash Firefox as well when set aside time for the tests. Have not used getDisplayMedia() at Firefox for testing as ordinarily do since the last comment. Will eventually try the code again at Nightly to test variations of screen shot code (https://github.com/w3c/mediacapture-screen-share/issues/107 ; https://github.com/w3c/mediacapture-screen-share/issues/108) at Mozilla browser. The most recent Nightly update lists the version as 69.0a1 (2019-05-30) (32-bit). As mentioned earlier, was not trying to reproduce the bug, but rather, avoid the bug. Created bug report so Firefox developers can be aware of the issue.

Flags: needinfo?(guest271314)

Jan-Ivar, it is certainly possible it could be a regression, or the same class of bug, which wouldn't surprise me. See Bug 1456101.

guest271314, it would be helpful to know exactly which OS, version, and architecture you are running.

guest271314, if it is the same class of problem as we have encountered before you should be able to switch to a console session by pressing ctrl + alt + F3 (The F keys that are bound to virtual consoles are generally F1 ... F6 but at least on my version of Ubuntu they start at F3). From there you can login and restart your X server. All running GUI apps will be killed but at least you don't have to restart. How one does that is dependent on your OS , distro, and version, but should be easy to find via your web search provider of choice.

Flags: needinfo?(na-g) → needinfo?(guest271314)

(In reply to Nico Grunbaum [:ng] from comment #12)

guest271314, it would be helpful to know exactly which OS, version, and architecture you are running.

guest271314, if it is the same class of problem as we have encountered before you should be able to switch to a console session by pressing ctrl + alt + F3 (The F keys that are bound to virtual consoles are generally F1 ... F6 but at least on my version of Ubuntu they start at F3). From there you can login and restart your X server. All running GUI apps will be killed but at least you don't have to restart. How one does that is dependent on your OS , distro, and version, but should be easy to find via your web search provider of choice.

Ubuntu 18.04.2 LTS (bionic) 4.15.0-20-lowlatency i686 live image. Tried ctrl alt F2 first to get to a shell. Then ctrl alt delete . Neither and no combination of keys was responsive. The keyboard and sleep mode were unresponsive as well. The only keyboard signal that worked was the power button. The mouse still moved, which was the only input that provided output. Tried the same code at Chromium at the same machine multiple times without any (noticeable) issues at the system level. An interesting bug.

Flags: needinfo?(guest271314)

(In reply to Nico Grunbaum [:ng] from comment #12)

What was the fix for the referenced bug?

Thanks for the info.

The previous bug was fixed by dispatching an X11 call to a different thread to avoid a deadlock in X11. IIRC the deadlock was caused by a bug in the X11 library that we use, but I would have to go back and do some more digging to say with confidence.

Just to be sure, you did try CTRL + A:T + F3 (or greater), and the Capslock/Numlock don't work?
This article[0] mentions some methods to try to recover from an X crash.

  • You can try pressing CTRL + SYSREQ + r which will take keyboard control away from X, then try CTRL + ALT + F(#).
  • CTRL + SYSREQ + k will kill all the programs you have running on a virtual console, including your X server.

[0] https://www.howtogeek.com/119293/4-ways-to-recover-from-a-crashed-or-frozen-x-server-on-linux/

Flags: needinfo?(guest271314)

(In reply to Nico Grunbaum [:ng] from comment #15)

Thanks for the info.

The previous bug was fixed by dispatching an X11 call to a different thread to avoid a deadlock in X11. IIRC the deadlock was caused by a bug in the X11 library that we use, but I would have to go back and do some more digging to say with confidence.

Just to be sure, you did try CTRL + A:T + F3 (or greater), and the Capslock/Numlock don't work?
This article[0] mentions some methods to try to recover from an X crash.

  • You can try pressing CTRL + SYSREQ + r which will take keyboard control away from X, then try CTRL + ALT + F(#).
  • CTRL + SYSREQ + k will kill all the programs you have running on a virtual console, including your X server.

[0] https://www.howtogeek.com/119293/4-ways-to-recover-from-a-crashed-or-frozen-x-server-on-linux/

From recollection tried to get to a shell prompt using CTRL ALT F2. The OS was unresponsive. When try again at Firefox will confirm. Even if a shell prompt is possible the result of calling getDisplayMedia() is still a bug. What should the user do at terminal besides kill Firefox and try to regain control of the system? Users that are familiar with terminal are not expecting JavaScript code run at the browser to freeze the OS.

Flags: needinfo?(guest271314)

(In reply to guest271314 from comment #16)

From recollection tried to get to a shell prompt using CTRL ALT F2. The OS was unresponsive. When try again at Firefox will confirm. Even if a shell prompt is possible the result of calling getDisplayMedia() is still a bug. What should the user do at terminal besides kill Firefox and try to regain control of the system? Users that are familiar with terminal are not expecting JavaScript code run at the browser to freeze the OS.

Sure, I am not proposing this as a solution. I am trying to determine if the behavior of the bug is the same as the bug mentioned above. That bug would lock up X, but otherwise leave the system running. One could get to the terminal and kill Firefox and then the desktop would unlock.

Thanks for your help so far.

OS: Unspecified → Linux
Priority: -- → P2
Hardware: Unspecified → x86

(In reply to Nico Grunbaum [:ng] from comment #17)

(In reply to guest271314 from comment #16)

From recollection tried to get to a shell prompt using CTRL ALT F2. The OS was unresponsive. When try again at Firefox will confirm. Even if a shell prompt is possible the result of calling getDisplayMedia() is still a bug. What should the user do at terminal besides kill Firefox and try to regain control of the system? Users that are familiar with terminal are not expecting JavaScript code run at the browser to freeze the OS.

Sure, I am not proposing this as a solution. I am trying to determine if the behavior of the bug is the same as the bug mentioned above. That bug would lock up X, but otherwise leave the system running. One could get to the terminal and kill Firefox and then the desktop would unlock.

Thanks for your help so far.

Some lines from ~/.xsession-errors

(/usr/lib/firefox/firefox:2737): Gtk-WARNING **: 05:53:33.174: Theme parsing error: gtk.css:2291:8: not a number

(/usr/lib/firefox/firefox:2737): Gtk-WARNING **: 05:53:33.175: Theme parsing error: gtk.css:2291:18: Using Pango syntax for the font: style property is deprecated; please use CSS syntax

(/path/to/firefox/firefox-bin:9325): Gtk-WARNING **: 08:08:32.377: Theme parsing error: gtk.css:4549:12: Expected a string.
[Child 5843, Chrome_ChildThread] WARNING: pipe error (3): Connection reset by peer: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 358

###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost


###!!! [Child][RunMessage] Error: Channel closing: too late to send/recv, messages will be lost


(firefox:16143): Gtk-WARNING **: 08:09:15.668: Theme parsing error: gtk.css:597:14: not a number

//..

(firefox:16143): Gtk-WARNING **: 08:09:15.680: Theme parsing error: gtk.css:2291:18: Using Pango syntax for the font: style property is deprecated; please use CSS syntax


//..

(/path/to/firefox/firefox-bin:27045): Gtk-WARNING **: 06:31:02.961: Theme parsing error: gtk.css:4549:12: Expected a string.
[20311:26695:0603/063539.047074:ERROR:simple_index_file.cc(327)] Failed to write the temporary index file
[20274:27227:0603/064023.982469:ERROR:simple_index_file.cc(327)] Failed to write the temporary index file
[20311:27218:0603/064645.854844:ERROR:simple_index_file.cc(327)] Failed to write the temporary index file
[20311:27385:0603/064715.766110:ERROR:simple_index_file.cc(327)] Failed to write the temporary index file

//..

[10744:10744:0604/143336.978922:ERROR:gl_surface_presentation_helper.cc(244)] GetVSyncParametersIfAvailable() failed for 666112 times!

Not sure if GetVSyncParametersIfAvailable() is based on Firefox or Chromium code tests. The specific Firefox entries are listed, which appear multiple times in the log file.

I am having this issue as well with this code executed in console in Firefox 70.0b2 (64-bit) on Ubuntu 19.04:

    navigator.mediaDevices.getDisplayMedia()
        .then((stream) => {
            this.stream = stream;
        }).catch((error) => {
            console.error("Error capturing screen",error);
        });

I can get control back if I SSH in and kill Firefox, so it does appear to be a deadlock issue.

I have been seeing this issue when the frame rate increases . I am guessing its something to do with encoding the share streams.

Is there a max frame rate resolution table which we can try to see if the freeze is not there . My settings is
maxWidth: 1920,
maxHeight: 1080,
frameRate: 30fps,

I am on the latest mac pro version . The same setting works find on other browser . I can provide some logs if steps provided

Flags: needinfo?(drno)

Duping this over to Bug 1558475.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Flags: needinfo?(drno)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: