fsamuel@: could your CLs (https://codereview.chromium.org/2521123004, https://codereview.chromium.org/2481263002) cause test failures?

fsamuel@: or this CL (https://codereview.chromium.org/2527443002)?

It's possible my changes caused these failures. I'll investigate today. I'm surprised the CQ bots didn't catch this.

Does #c3 mean that mus/mash failures in the Sheriff-o-Matic can be ignored for now?  At this point Sheriff-o-Matic reports consistent failures in mus_ws_unittests on the "Linux Tests" and "Win 7 Tests x64 (1)" builders.  Additionally there are also some consistent failure in views_mus_interactive_ui_tests.

(Sheriff) I'll revert both suspicious CLs because the bots are still failing.

Reverting the CLs could be tough because other CLs depend on them:
https://codereview.chromium.org/2527003002/

fsamuel@ just found the cause and is now actively making a fix it. I'll wait for the fix for a while.

famuel@: please let me know if you find it difficult to land the fix soon. In the case, I'll try to revert them again.

I think I have a fix. As far as I can tell, this is a tear down issue. We need to tear down the display compositor thread prior to tearing down the gpu thread. The display compositor depends on state in GpuServiceInternal. Thus depending on ordering of operations, it can crash or deadlock. I think I have a fix that tears down the display compositor first from the main thread, then tears down GpuServiceInternal on the gpu thread. The code needs some cleanup later this week but for now this should fix the flakiness.

The fix (https://codereview.chromium.org/2527003002/) cannot pass the tryservers because of the infra issue.  nhiroki@ tries to land this using NOTRY.

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

commit 5059e49d0a21c1c311653c1613de16b27aefc963
Author: fsamuel <fsamuel@chromium.org>
Date: Thu Nov 24 10:28:09 2016

Mus: Avoid deadlock during teardown

The display compositor blocks on the gpu thread to tear down. If
GpuServiceInternal tears down before display compositor has a chance
to tear down then Mus may crash during tear down or deadlock waiting
for a task to execute that never will.

BUG= 668105 
TBR=sadrul@chromium.org, sky@chromium.org
NOTRY=true
NOPRESUBMIT=true

Review-Url: https://codereview.chromium.org/2525213002
Cr-Commit-Position: refs/heads/master@{#434310}

[modify] https://crrev.com/5059e49d0a21c1c311653c1613de16b27aefc963/services/ui/gpu/gpu_main.cc
[modify] https://crrev.com/5059e49d0a21c1c311653c1613de16b27aefc963/services/ui/gpu/gpu_main.h
[modify] https://crrev.com/5059e49d0a21c1c311653c1613de16b27aefc963/services/ui/gpu/gpu_service_internal.cc
[modify] https://crrev.com/5059e49d0a21c1c311653c1613de16b27aefc963/services/ui/gpu/gpu_service_internal.h
[modify] https://crrev.com/5059e49d0a21c1c311653c1613de16b27aefc963/services/ui/surfaces/display_compositor.cc
[modify] https://crrev.com/5059e49d0a21c1c311653c1613de16b27aefc963/services/ui/surfaces/display_compositor.h

 Issue 668412  has been merged into this issue.

Builders are green.