I don't work on the Linux sandbox, and I don't have a Kevin, but maybe I can help with more information. Do you have logs from Chrome when it fails to start? What does it say?

@kerrnel, who is the sandbox person for Chrome OS?

Attached is the ui.LATEST log.

Deleted: ui.LATEST 21.4 KB

ui.LATEST 21.4 KB Download

It seems the fatal error is this:

[3508:3508:0404/124831.036615:FATAL:sandbox_linux.cc(341)] InitializeSandbox() called with multiple threads in process gpu-process. This error can be safely ignored in VMTests.

Coming from: https://cs.chromium.org/chromium/src/content/common/sandbox_linux/sandbox_linux.cc?q=sandbox_linux.cc&dr&l=329

But this doesn't make sense. That code explicitly states that the error should not be fatal in the gpu-process. 

Unless "gpu-sandbox-failures-fatal" somehow got set, I'm not sure how that code could trigger the FATAL error.

Justin, who is the sandbox person for Linux/Chrome OS?

Hopefully jln@ or jorgelo@ can help.

The problem is that we're hitting that LOG(FATAL) even with --no-sandbox on. Stéphane, any change in how flags are propagated? Or how the GPU process receives its flags?

I also don't have a Kevin, will ask vapier@ if he has one.

Mike doesn't have one, if this is specific to Kevin I will need one shipped to me.

It definitely doesn't happen on x86 devices, so you are probably better off getting a Kevin. We are selling it right now, so I'm sure chromestop can provide you with one.

I can email crosdistros@ and see what they say.

Quick update here: still waiting for a Kevin.

@12: is one on the way?  Do you need any expediting / approvals, or is this just the slowness of shipping stuff?

One is on the way indeed.

I got the kevin yesterday. I was able to repro the issue today. Still clueless as to why it's happening.

We seem to indeed ignoring the --no-sandbox flag:

[8368:8368:0414/075639.045520:ERROR:sandbox_linux.cc(299)] process_type gpu-process --no-sandbox 1
[8368:8368:0414/075639.059791:ERROR:sandbox_linux.cc(299)] process_type gpu-process --no-sandbox 1

Here's what happens:

On mali, we try to start the sandbox early
But we end up not doing that because of --no-sandbox
Then we come to the sandbox init for all other GPUs
And we try again because we're not sandboxed because of --no-sandbox
And this time we fail because of threads (which get checked before --no-sandbox).

Fix at https://codereview.chromium.org/2814793007/, to avoid attempting the second sandbox init when the first one was already attempted.

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

commit 754f1ec2c538c710a8a5bf304643acd89f106db0
Author: jorgelo <jorgelo@chromium.org>
Date: Fri Apr 21 01:27:07 2017

Fix --no-sandbox and --disable-gpu-sandbox on Mali.

On Mali GPUs we try to start the sandbox early, before the driver
spawns threads. Because of --no-sandbox, we don't actually start the
sandbox. |gpu_info.sandboxed| will then be false, so at the bottom of
the InitializeAndStartSandbox function we'll try to start the sandbox
again, but at this time the Mali driver will have already started
threads and we'll LOG(FATAL).

Fix by not attempting the second sandbox start when the early one
was attempted.

BUG= 707461 
TEST=Build for Kevin, add --no-sandbox to the cmdline, UI starts.
TEST=Add --disable-gpu-sandbox to the cmdline, UI starts.
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/2814793007
Cr-Commit-Position: refs/heads/master@{#466212}

[modify] https://crrev.com/754f1ec2c538c710a8a5bf304643acd89f106db0/gpu/ipc/service/gpu_init.cc