Closed Bug 1282425 Opened 8 years ago Closed 8 years ago

Window sharing fails on Ubuntu 16.04 test machines

Categories

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

Product:
Core
Component:
WebRTC: Audio/Video
Platform:
Unspecified
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: dminor, Unassigned)

References

Details

See try run here [1], it appears anything to do with window sharing fails on the Ubuntu 16.04 AWS testers. [1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=c566e0d36254e482e70fd57b250a22d9c037623e&selectedJob=22893835
thanks for checking this out and summarizing ths. please let me know if there are OS specific features that need to change, I would be happy to modify, regenerate and run the tests again.
I'm guessing it is something with the xvfb configuration based on the "NotFoundError" - the tests pass when I run them locally on 16.04. Before I dig into this, :jib do you have any suggestions as to what might cause this to fail? Thanks!
Flags: needinfo?(jib)
NotFoundError in GUM [1] means the screenshare device was not in the list of enumerated devices [2]. Maybe the device failed to initialize? Is this a regression? Maybe a regression range would help. [1] https://dxr.mozilla.org/mozilla-central/rev/c2da34d96746288b5fee27bf6542a12c9f410988/dom/media/MediaManager.cpp#2125 [2] https://dxr.mozilla.org/mozilla-central/rev/c2da34d96746288b5fee27bf6542a12c9f410988/dom/media/webrtc/MediaEngineWebRTC.cpp#200
Flags: needinfo?(jib)
Thanks! This isn't a regression, the test machines are being updated from Ubuntu 12.04 to 16.04.
I see this in the log while starting up the docker container: + xvinfo + Xvfb :0 -nolisten tcp -screen 0 1600x1200x24 xvinfo: Unable to open display :0 + xvfb_test=255 + '[' 255 '!=' 255 ']' + retry_count=1 + echo 'Failed to start Xvfb, retry: 1' Failed to start Xvfb, retry: 1 + sleep 2 + '[' 1 -gt 2 ']' + xvinfo X-Video Extension version 2.2 screen #0 no adaptors present + xvfb_test=1 + '[' 1 '!=' 255 ']' + retry_count=3 + '[' 3 -gt 2 ']' + '[' 1 == 255 ']' let me see if there is something I can fix the "no adaptors present", as that is likely to be the root cause.
on a 12.04 machine, I still get: X-Video Extension version 2.2 screen #0 no adaptors present
I would like to think that I have parity in both 12.04 and 16.04, I am open to hacking a bit, do let me know if there are ideas.
:dminor, do you have thoughts on what I might be able to try from the OS end? Or should we just wait for some cycles to look at the test side in more detail?
(In reply to Joel Maher (:jmaher) from comment #8) > :dminor, do you have thoughts on what I might be able to try from the OS > end? Or should we just wait for some cycles to look at the test side in > more detail? I'm almost certain we're missing something on the OS side, but I'm not sure what. My plan was to add some printfs/logging into the screen sharing code, starting in media/webrtc/trunk/webrtc/modules/desktop_capture/x11/desktop_device_info_x11.cc and see if I can get more info from a try run (or *shudder* install docker on my system). I should have time for this early next week. It would help if I knew what the motivation for moving these tests to 16.04 was, at the moment it seems like work that should definitely happen in Q3, but not something I need to drop my current work to support. If this is blocking something high priority, please let me know and I'll adjust my priorities accordingly.
:k17e requested mda jobs to be run on ubuntu16.04 for the upgrade ffmpeg tools. I don't think this is priority #1, so next week is fine.
From this try run [1], it appears that the firefox window is just not showing up to X11: Ubuntu 16.04: 21:12:23 INFO - >>>> MediaEngineWebRTC::EnumerateVideoDevices 21:12:23 INFO - DesktopCaptureImpl::CreateDeviceInfo 21:12:23 INFO - >>>> DesktopCaptureImpl::CreateDeviceInfo: 65535 3 21:12:23 INFO - >>>> WindowCapturerLinux ctor 21:12:23 INFO - >>>> has composite extension 21:12:23 INFO - >>>> pWinCap -> 1 21:12:23 INFO - >>>> WindowCaptuerLinux::GetWindowList 21:12:23 INFO - >>>> WindowCaptuerLinux::GetWindowList: screens 1 21:12:23 INFO - >>>> WindowCapturerLinux ctor 21:12:23 INFO - >>>> has composite extension 21:12:23 INFO - >>>> pWinCap -> 1 21:12:23 INFO - >>>> WindowCaptuerLinux::GetWindowList 21:12:23 INFO - >>>> WindowCaptuerLinux::GetWindowList: screens 1 21:12:23 INFO - >>>> NumberOfCaptureDevices: 0 21:12:23 INFO - >>>> found 0 sources Ubuntu 12.04: 13:47:34 INFO - 1951 INFO TEST-START | dom/media/tests/mochitest/test_getUserMedia_basicWindowshare.html 13:47:34 INFO - TEST DEVICES: Using media devices: 13:47:34 INFO - audio: Sine source at 440 Hz 13:47:34 INFO - video: Dummy video device 13:47:34 INFO - >>>> MediaEngineWebRTC::EnumerateVideoDevices 13:47:34 INFO - DesktopCaptureImpl::CreateDeviceInfo 13:47:34 INFO - >>>> DesktopCaptureImpl::CreateDeviceInfo: 65535 3 13:47:34 INFO - >>>> WindowCapturerLinux ctor 13:47:34 INFO - >>>> has composite extension 13:47:34 INFO - >>>> pWinCap -> 1 13:47:34 INFO - >>>> WindowCaptuerLinux::GetWindowList 13:47:34 INFO - >>>> WindowCaptuerLinux::GetWindowList: screens 1 13:47:34 INFO - >>>> adding window: 56623136 13:47:34 INFO - >>>> DesktopDeviceInfoImpl: 56623136 MochiTest | /tests - Nightly 13:47:34 INFO - >>>> WindowCapturerLinux ctor 13:47:34 INFO - >>>> has composite extension 13:47:34 INFO - >>>> pWinCap -> 1 13:47:34 INFO - >>>> WindowCaptuerLinux::GetWindowList 13:47:34 INFO - >>>> WindowCaptuerLinux::GetWindowList: screens 1 13:47:34 INFO - >>>> adding window: 56623136 13:47:34 INFO - >>>> DesktopDeviceInfoImpl: 56623136 MochiTest | /tests - Nightly 13:47:34 INFO - >>>> NumberOfCaptureDevices: 1 13:47:34 INFO - >>>> RecvGetCaptureDevice: 3 0 13:47:34 INFO - >>>> Capture Device Index 0, Name MochiTest | /tests - Nightly 13:47:34 INFO - >>>> RecvGetCaptureDevice: 3 0 13:47:34 INFO - >>>> found 1 sources 13:47:34 INFO - >>>> source: MochiTest | /tests - Nightly 13:47:34 INFO - >>>> WindowCapturerLinux ctor 13:47:34 INFO - >>>> has composite extension Which is more or less what the javascript error was telling us, but it's nice to know that it's definitely at the X11 level and not something going wrong along the way in firefox. [1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=1d5aa03746571134dd0e43407b4922f69b0d9f1a
I was able to duplicate the problem locally running Xvfb. It started working if I also started a window manager. We attempt to do that in the test setup, but it appears that it may be failing silently.
It looks like Joel was able to get this fixed in his latest try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ce1a8a818381de587a4e25774b3272e7cd9e72d4&selectedJob=23668241
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.