New issue
Advanced search Search tips

Issue 686092 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Mar 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 664570



Sign in to add a comment

Fix Ozone X11 PlatformEventSource with tests

Project Member Reported by kylec...@chromium.org, Jan 27 2017

Issue description

I'm looking at why tests from linux_chromium_chromeos_ozone_rel_ng fail running on Ozone X11 but pass with Ozone headless. I think the biggest issue is the PlatformEventSource.

During OzonePlatformX11::InitializeForUI() and OzonePlatformX11::InitializeForGPU() a PlatformEventSource is instantiated. It's a X11EventSourceLibevent in particular. So any tests that initialize Ozone need to be able to construct that object.

X11EventSourceLibevent needs both a TYPE_UI message loop and a X display available. Tests usually use TYPE_DEFAULT message loop and only tests that run with Xvfb have an X display available. This leads to a DCHEK failure somewhere and the test crashes.

The tests don't actually send XEvents through PlatformEventSource, so there is no need to have a real X11EventSourceLibevent. Ozone headless just instantiates a stub PlatformEventSource. We could use a stub PlatformEventSource for Ozone X11 tests too.
 

Comment 1 by sadrul@chromium.org, Jan 27 2017

Yeah, that sounds good. We do that in a few non ozone tests too.
Looking into this a bit further, for tests that actually create a XWindow we need a PlatformEventSource. These tests are already type 'windowed_test_launcher' so they will run with Xvfb. The issue is the message loop isn't TYPE_UI. The Linux X11 and X11 Chrome OS builds use glib instead libevent, and glib doesn't require TYPE_UI.
Labels: Proj-Mustash
Owner: toniki...@chromium.org
Status: Assigned (was: Untriaged)
https://codereview.chromium.org/2629983002 is on the way to fixing this.

Cc: julien.isorce@chromium.org
I've been in the process of fixing Ozone X11 tests and I've got a couple of PlatformEventSource issues fixed. I don't think we need a stub PlatformEventSource implementation after all. Every test that initializes OzoneX11 actually needs XEvents.

There are two tests, gpu_unittests and gpu_ipc_service_unittests, that need to initialize the correct MessageLoop type. This is blocked on https://codereview.chromium.org/2629983002 but should be an easy fix after that is submitted.
Project Member

Comment 6 by bugdroid1@chromium.org, Feb 8 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb807b102e67eb2dfb2bc2318a5c913a021350b8

commit fb807b102e67eb2dfb2bc2318a5c913a021350b8
Author: tonikitoo <tonikitoo@igalia.com>
Date: Wed Feb 08 19:52:03 2017

Fix the MessageLoop type in case more than one ozone platform is built

One of the premises of Ozone is that one can trigger
a backend at runtime. For example, if one has

  ozone_platform_x11=true
  ozone_platform_wayland=true

.. in the GN args, it should be able to launch either backend
by passing --ozone-platform=x11|wayland. This enforces no compile
time branches where possible.
In [1], a OZONE_X11 define was added, and slightly breaks that
premise.

This CL fixes it by:

- making OzonePlatform::CreateInstance public (and renaming it to
  ::EnsureInstance). This allows the creation of the OzonePlatform
  instance without doing any actual initialization.

- Adding a OzonePlatform::GetMessageLoopTypeForGpu virtual method,
  which returns the MessageLoop type required for the GPU depending
  on the Ozone platform selected at runtime.

[1] https://codereview.chromium.org/1723303002

BUG= 640613 , 686092 

Review-Url: https://codereview.chromium.org/2629983002
Cr-Commit-Position: refs/heads/master@{#449068}

[modify] https://crrev.com/fb807b102e67eb2dfb2bc2318a5c913a021350b8/content/gpu/BUILD.gn
[modify] https://crrev.com/fb807b102e67eb2dfb2bc2318a5c913a021350b8/content/gpu/gpu_main.cc
[modify] https://crrev.com/fb807b102e67eb2dfb2bc2318a5c913a021350b8/services/ui/gpu/gpu_main.cc
[modify] https://crrev.com/fb807b102e67eb2dfb2bc2318a5c913a021350b8/ui/ozone/platform/x11/ozone_platform_x11.cc
[modify] https://crrev.com/fb807b102e67eb2dfb2bc2318a5c913a021350b8/ui/ozone/public/ozone_platform.cc
[modify] https://crrev.com/fb807b102e67eb2dfb2bc2318a5c913a021350b8/ui/ozone/public/ozone_platform.h

Cc: toniki...@chromium.org
Owner: kylec...@chromium.org
After https://codereview.chromium.org/2629983002 , I am heading this back to Kyle, who is taking the lead here.
Project Member

Comment 8 by bugdroid1@chromium.org, Feb 28 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ffae7e0a3390a6f07620f47f95d5d00a0a887f66

commit ffae7e0a3390a6f07620f47f95d5d00a0a887f66
Author: kylechar <kylechar@chromium.org>
Date: Tue Feb 28 15:09:36 2017

Change MessageLoop type for GPU tests with Ozone.

Some Ozone platforms require a specific MessageLoop type in the GPU.
Namely, this is Ozone X11 that depends on libevent which in turn needs
TYPE_UI message loop to get XEvents.

When initializing the GPU process we check
OzonePlatform::GetMessageLoopTypeForGPU() to get the message loop type.
Do something similar for gpu_unittets and gpu_ipc_service_unittests so
that they can pass with Ozone X11.

Those tests will still run by default with Ozone headless on
linux_chromium_chromeos_ozone_rel_ng. This can be changed later if the
tests appear stable on an FYI bot with Ozone X11.

BUG= 686092 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2682393003
Cr-Commit-Position: refs/heads/master@{#453602}

[modify] https://crrev.com/ffae7e0a3390a6f07620f47f95d5d00a0a887f66/gpu/BUILD.gn
[modify] https://crrev.com/ffae7e0a3390a6f07620f47f95d5d00a0a887f66/gpu/command_buffer/service/gles2_cmd_decoder_unittest_base.cc
[modify] https://crrev.com/ffae7e0a3390a6f07620f47f95d5d00a0a887f66/gpu/command_buffer/service/gpu_service_test.cc
[modify] https://crrev.com/ffae7e0a3390a6f07620f47f95d5d00a0a887f66/gpu/ipc/service/BUILD.gn
[modify] https://crrev.com/ffae7e0a3390a6f07620f47f95d5d00a0a887f66/gpu/ipc/service/gpu_channel_unittest.cc
[add] https://crrev.com/ffae7e0a3390a6f07620f47f95d5d00a0a887f66/gpu/test_message_loop_type.h

Status: Fixed (was: Assigned)
Status: Started (was: Fixed)
Project Member

Comment 11 by bugdroid1@chromium.org, Mar 28 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1580a1f7b520c8ab7e6ff12c08c227ecc19df7cd

commit 1580a1f7b520c8ab7e6ff12c08c227ecc19df7cd
Author: kylechar <kylechar@chromium.org>
Date: Tue Mar 28 14:10:42 2017

Revert changes to GPU test MessageLoop type.

Some GPU tests were changed to initialize a specific message loop type
with Ozone in http://crrev.com/2682393003. This is no longer necessary
after changing how Ozone GPU is initialized for tests in
http://crrev.com/2773503003.

BUG= 686092 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2778833002
Cr-Commit-Position: refs/heads/master@{#460089}

[modify] https://crrev.com/1580a1f7b520c8ab7e6ff12c08c227ecc19df7cd/gpu/BUILD.gn
[modify] https://crrev.com/1580a1f7b520c8ab7e6ff12c08c227ecc19df7cd/gpu/command_buffer/service/gles2_cmd_decoder_unittest_base.cc
[modify] https://crrev.com/1580a1f7b520c8ab7e6ff12c08c227ecc19df7cd/gpu/command_buffer/service/gpu_service_test.cc
[modify] https://crrev.com/1580a1f7b520c8ab7e6ff12c08c227ecc19df7cd/gpu/ipc/service/BUILD.gn
[modify] https://crrev.com/1580a1f7b520c8ab7e6ff12c08c227ecc19df7cd/gpu/ipc/service/gpu_channel_unittest.cc
[delete] https://crrev.com/df30c0f4735e673c03e43a0c77eec1ee5cdd9653/gpu/test_message_loop_type.h

Status: Fixed (was: Started)

Comment 13 by dchan@google.com, May 30 2017

Labels: VerifyIn-60
Labels: VerifyIn-61

Comment 15 by dchan@chromium.org, Jan 22 2018

Status: Archived (was: Fixed)

Sign in to add a comment