http://uberchromegw/i/chromeos.chrome/builders/caroline-tot-chrome-pfq-informational/builds/797 failed too. Same crashes as above, plus one in v8::internal::Page::FromAddress via ash::mojo_interface_factory::(anonymous namespace)::BindAshDisplayControllerRequestOnMainThread.

Deleted: mojo_ash_display_controller.txt 77.6 KB

mojo_ash_display_controller.txt 77.6 KB View Download

Robert, any chance that https://crrev.com/c/861749 caused this? It looks like it made some changes to initialization in ui/ozone/platform/drm/host, and the timing lines up with the earliest occurrences I've seen of these failures.

(Sorry if viz is the wrong component for this bug.)

I ran James's ui.MashLogin Tast test (https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/master/src/chromiumos/tast/local/bundles/cros/ui/mash_login.go), which does the same thing as the desktopui_MashLogin Autotest-based test. It fails with a crash at ToT and passes after I revert https://crrev.com/c/861749 locally.

Created a revert at https://crrev.com/c/876936.

How can I replicate this failure?

chrome --mash in ToT (without my patch) doesn't actually work on device: it comes up long enough to paint the task runner window and then crashes in the unlock screen. My reverted CL didn't alter this for the better or worse -- it only perturbed the timing.

Do we expect chrome --mash to work? If not, let's get it off the pfq? Or if we do, let's get it possible to use?

(James can hopefully answer those questions.)

The problem replicates with DCHECKs disabled. With DCHECKs enabled, desktopui_MashLogin fails on both ToT and with https://crrev.com/c/861749.

chrome --mash was working on device when I was last in MTV, a week ago Friday. I think I was using a caroline at the time.

desktopui_MashLogin appears to be passing on the Chrome OS waterfall, except for the eve family of boards (where it has been crashing on startup since November due to a page flip issue).

https://stainless.corp.google.com/search?exclude_retried=true&exclude_cts=false&exclude_non_production=true&exclude_acts=true&exclude_non_release=true&exclude_au=true&test=desktopui_MashLogin&exclude_not_run=false&row=board&col=build&view=matrix&first_date=2018-01-10&last_date=2018-01-23

The eve family of boards are not in the PFQ, so these failures won't block Chrome uprev on Chrome OS.

Autotest failures can be reproduced with instructions here: https://www.chromium.org/chromium-os/developer-guide -- once you have a working OS checkout, see the section "Running Tests".

If Chrome is crashing on startup, a stack trace would be helpful.

(See stack traces earlier in bug.)

Fixed.

Which CL fixed this?

The revert.