cros_vm_sanity_test is a smoke check of the browser. It launches chrome, logs in, executes some javascript. I think it loads the chrome://about page too.

As for the rest of your questions... I can't really speak to them (bit out of my purview), but I might have an idea as to what's happening here:

- In the failures you saw in the CL, the compiler bots package up test binaries and ship them to the test bots. The full list of files included is:
https://isolateserver.appspot.com/browse?namespace=default-gzip&hash=b4590d3b04d67aade7dc9bdda3b0f34a64a93c0a
- That list includes chrome_100_percent.pak, but not chrome_200_percent.pak.
- We deploy that list to the default chrome dir on the cros VM (/opt/google/chrome/).
- That dir comes shipped with a known-good deployment of chrome thats ~a few days old... and when we deploy your CL's version of chrome, we overwrite what's already there.
- So we ended up with a deployment of chrome that had a up-to-date version of chrome_100_percent.pak... but a much older chrome_200_percent.pak


That, I think, is the cause of the crashes you saw... but I'm not 100% sure. (What do the chrome_X_percent.pak files contain? I'm assuming pngs? Maybe the exact pngs chrome is failing to load here?) Does that sound right? If so, there's a couple bugs here:

- Add chrome_200_percent.pak to the shipped test dependency files. The list of files is generated via a test target's GN deps... so it's strange that they'd be missing. I'll track it down and figure out why they aren't present.
- Deploy chrome on the CrOS VM to a clean dir/stop trying to overwrite the default dir. Kind of a no-brainer now that I think of it... a bit surprising it took me this long to realize. Fortunately, I think that's a pretty straightforward fix. I'll get to that too.

Ben, thanks for investigating! Regarding `chrome_200_percent.pak`, looks like we intentionally do not generate it on CrOS, see:

https://cs.chromium.org/chromium/src/chrome/chrome_paks.gni?rcl=d3ccf6b5b0b0dd14e2fe459881496f563e2dedb2&l=220

We generate it (or at least we do on HiDPI devices... which I think is all CrOS devices), we just don't add it to the data. Uploaded https://chromium-review.googlesource.com/c/chromium/src/+/1197826 which should fix that.

Also uploaded https://chromium-review.googlesource.com/c/chromiumos/chromite/+/1198502 to prevent us from reusing chrome artifacts from a previous deployment/test.

Once those land, we should no longer be susceptible to the errors you were seeing earlier.

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

commit 58b56083c8d1cb617cc215bbf5f1530198e271c8
Author: Ben Pastene <bpastene@chromium.org>
Date: Wed Sep 05 20:20:24 2018

Add chrome_200_percent.pak to a chrome_binary's data on HiDPI platforms.

The pak file gets generated when building chrome for HiDPI:
https://codesearch.chromium.org/chromium/src/chrome/chrome_paks.gni?rcl=9a8cfdf0edde3f7d61d08b5890a94c038a15f3fb&l=220

But it doesn't show up in the target's data. Consequently, it's missing
from tests' isolate. This should fix that.

Bug: 878730
Change-Id: I1e95c41a18cfe88a83235b42605c53829f9a344f
Reviewed-on: https://chromium-review.googlesource.com/1197826
Reviewed-by: John Budorick <jbudorick@chromium.org>
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Cr-Commit-Position: refs/heads/master@{#588986}
[modify] https://crrev.com/58b56083c8d1cb617cc215bbf5f1530198e271c8/chrome/BUILD.gn