New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 859246 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug

Blocking:
issue 840967



Sign in to add a comment

Fix ozone related crashes for UI tests on CrOS

Project Member Reported by bpastene@chromium.org, Jun 30 2018

Issue description

As part of bug 840967, we're trying to run chromium's tests in ChromeOS VMs on the CQ. A large chunk of UI-related suites crash in the VMs due to the following ozone initialization error:

"""
Failed to get out-of-band test success data, dumping full stdio below:
[4375:4375:0629/164206.887427:158287020:FATAL:thread_task_runner_handle.cc(29)] Check failed: current. Error: This caller requires a single-threaded context (i.e. the current task needs to run from a SingleThreadTaskRunner).
#0 0x5b40cd0aa8ec base::debug::StackTrace::StackTrace()
#1 0x5b40cd0527e0 logging::LogMessage::~LogMessage()
#2 0x5b40cd08723b base::ThreadTaskRunnerHandle::Get()
#3 0x5b40ccc88994 ui::(anonymous namespace)::OzonePlatformGbm::InitializeGPU()
#4 0x5b40ccc4d2a5 ui::OzonePlatform::InitializeForGPU()
#5 0x5b40cc0d0afa (anonymous namespace)::ServiceTestSuite::Initialize()
#6 0x5b40cd272dc3 base::TestSuite::Run()
#7 0x5b40cd279e40 base::(anonymous namespace)::LaunchUnitTestsInternal()
#8 0x5b40cd279cd7 base::LaunchUnitTests()
#9 0x5b40cd044fff service_manager::InitializeAndLaunchUnitTests()
#10 0x5b40cc0d0a2b main
#11 0x7e83ff3f4736 __libc_start_main
#12 0x5b40cbb371b9 _start
"""

See also https://ci.chromium.org/p/chromium/builders/luci.chromium.try/chromeos-amd64-generic-rel/36923 where I tried running services_unittests in the VMs. It looks like any suite that calls "ui::OzonePlatform::InitializeForGPU" in its initialization fails like this.
https://codesearch.chromium.org/search/?q=%22ui::OzonePlatform::InitializeForGPU%22+file:test&sq=package:chromium&type=cs

Is that expected? Is it possible to get the crash resolved? (I can help/give pointers on how to repro it if needed; it should be pretty straight forward.)
 
Looks like we are initializing without a message loop, which breaks some assumptions.

Note the code that's crashing takes ownership of the display. You must serialize execution of these tests if you run with GBM platform - only one task can own the display at a time.

It may not be worth it to run the tests this way. You could instead run headless; just add --ozone-platform=headless to command line flags.
Cc: mcasas@chromium.org dcasta...@chromium.org
Labels: Proj-Ozone
Owner: rjkroege@chromium.org
Status: Available (was: Untriaged)
Status: Assigned (was: Available)
Bug available and with an owner? madness ! :-)
Cc: steve...@chromium.org achuith@chromium.org
Re #1: Thanks for the explanation. Explicitly passing in the headless arg does indeed avoid the crash. (Also had to tweak gn args to support ozone_platform_headless.) 

> It may not be worth it to run the tests this way.

I was thinking that it might be useful. We're trying to build and run these tests on real chromeos devices, and IIUC gbm is the platform chrome uses on chromeos. I imagine there'd be some value out of targeting the same platform used in production on that OS. But I could certainly be wrong there.

For now, I'll work on running these tests in headless mode on our cros bots. If someone tells me that gbm mode would be worth it (and it's compatible) I'll switch them over :)
It would probably work fine if the test executable is fixed to provide the message loop and the tests are run serially.

Comment 7 Deleted

Apologies, ignore the last comment, that was for an M69 build running in the lab. Recent builds don't show this crash.

Sign in to add a comment