mohsen, can you take a look?

git bisect shows this is the first bad commit:

commit f9505d8d7411d13996368054a7d24fd88ac629c2
Author: Mohsen Izadi <mohsen@chromium.org>
Date:   Sat Oct 6 01:34:03 2018 +0000

    Use viz::GpuHostImpl in OopAsh
    
    This CL updates ws::gpu_host::GpuHost to use viz::GpuHostImpl as its
    implementation for viz::mojom::GpuHost. It does not replace ws::GpuHost
    completely as it still depends ws::GpuClient. A follow-up CL would
    replace ws::GpuClient with viz::GpuClient. Then we can probably remove
    ws::GpuHost.
    
    BUG= 841446 
    
    Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel
    Change-Id: Ibec183545d235803d6206b93aac27055a72bde26
    Reviewed-on: https://chromium-review.googlesource.com/c/1239336
    Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
    Reviewed-by: Scott Violet <sky@chromium.org>
    Reviewed-by: Antoine Labour <piman@chromium.org>
    Commit-Queue: Mohsen Izadi <mohsen@chromium.org>
    Cr-Commit-Position: refs/heads/master@{#597392}

I couldn't cleanly revert because other CLs have landed on top.

I tried this on ToT and I could repro on every run. Then I tried a bisect (as it doesn't seem related to my CL) and I was unable to repro on any revision until I reached ToT again and I'm unable to repro on ToT anymore.

Can anyone repro this? Is there something I can try to help repro?

I couldn't reproduce this on a debug ToT build either. Mike or James, can you still repro? Are you using Debug or Release?

I tried Debug.

I just tried Release and could not repro there, either.

It did repro for me on 4/5 attempts using Release with DCHECKS at #600836:
1) It did repro using an existing user-data-dir (a)
2) It did *not* repro with a fresh user-data-dir (b)
3) It did repro re-uisng that fresh user-data-dir (b)
5) It did repro with another fresh user-data-dir (c)
It seems like some init is flaky...

Still unable to repro in any of the above conditions using Release with DCHECKS at r600836!

Repros for me 5 of 5 times with Release with DCHECKs at r601224, fresh user data dir each time.

HP z840 with Rodete. gn args:

dcheck_always_on = true
is_debug = false
is_component_build = true
remove_webcore_debug_symbols=true
target_os = "chromeos"
use_goma = true

out/Default/chrome --ash-host-window-bounds="0+800-1024x768" --user-data-dir=/tmp/udd335 --enable-features=Mash

Reproduced 1 of 5 times in Debug at same revision.

args.gn:
use_goma = true
is_debug = true
is_component_build = true
target_os = "chromeos"

symbol_level = 2
remove_webcore_debug_symbols=true

Thanks James. I finally managed to repro it on ToT, not reliably though. I also could repro it on r597392, too, but not on r597391. So, it seems that my CL is indeed the culprit.

Interestingly, removing or changing the value of --ash-host-window-bounds affects the behavior!

I'll look further into it...

FYI - I'm still seeing this periodically.

I'm still seeing this consistently on linux-chromeos Debug and Release, and it's going to start blocking our work very soon.
Are there any updates here, any workarounds or ways to reduce the frequency of repro? I tried some custom --ash-host-window-bounds to no avail.

No updates, sorry! I was not able to repro this enough so I can debug it. And since it was only happening in the multi-process mash, I had put it aside for the moment. Apparently it is now happening more. I'll take another look...