Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.

I tried on my mac desktop and mac laptop, and with Canary (exactly @515409) and ToT, and can't reproduce this.

For the mac machines you can reproduce this, please provide the about:gpu content.

Interestingly, I can only reproduce this on Linux.

If I run Chrome Linux, open task manager, crash GPU process three times, task manager will froze.

If I run Chrome Linux with --disable-software-rasterizer, the issue goes away.

With my CL, when we switch from GPU process running with hardware to GPU process running with SwiftShader, we don't block GPU compositing right away (before we did). Now we wait for the GPU process to launch, and learn that GPU compositing is blacklisted with SwiftShader.

Apparently the compositor for task manager doesn't fallback in this situation.

When the freeze happens, we got the following log:

[1:10:1110/170505.370233:ERROR:command_buffer_proxy_impl.cc(118)] ContextResult::kFatalFailure: Shared memory handle is not valid
[1:10:1110/170505.370387:ERROR:context_provider_command_buffer.cc(245)] GpuChannelHost failed to create command buffer.

Note that it's not always the task manager window gets frozen. Sometimes it's the tab (renderer).

https://chromium-review.googlesource.com/c/chromium/src/+/767291 should address this regression.

Working on the underlying root cause of this flakiness.

1) there are two compositors, one for the renderer, one for the task manager. When GPU process crashes three times and hardware GPU is disabled, it really depends on which compositor's GPU channel gets connected first.  The one who gets GPU channel back first will realize GPU compositing is disabled, so it disable GPU compositing for the other compositor. The second one gets a GPU channel, also realizes GPU compositing is disabled, but somehow it gets stuck.

2) In GpuProcessTransportFactory::DisableGpuCompositing, if we don't touch the other compositors, then both compositors fall back to the software mode correctly.

Here is some more analysis:

After the third time GPU process crashed, both compositors call RequestNewLayerTreeFrameSink(), which in turn call CreateLayerTreeFrameSink(), and layer_tree_frame_sink_requested_ isn't set to true.

Now the first GPU channel comes back to compositor A, and it tries to disable GPU compositing for both compositors.

In DisableGpuCompositing(), compositor B is removed from GpuProcessTransportFactory through ReleaseAcceleratedWidget(), and in SetAcceleratedWidget, because layer_tree_frame_sink_requested_ wasn't set to true, so CreateLayerTreeFrameSink() wasn't triggered.

Then Gpu channel was established for compositor B, but at this point, compositor B has been removed from GpuProcessTransportFactory, so early exit.

Compositor B ends up without a LayerTreeFrameSink.

A new fix is uploaded: https://chromium-review.googlesource.com/c/chromium/src/+/769328

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

commit c3c48528bba261dddc1550c3f8c6d3ffa0f4ff5e
Author: Zhenyao Mo <zmo@chromium.org>
Date: Tue Nov 14 21:25:53 2017

Fix a racing in compositor falling back from GPU to software mode

It can be reproduced while GPU process crashes three times and hardware
acceleration gets blocked.

Also, revert a unittest added for the reverted fix.

BUG= 783728 
TEST=manual
R=piman@chromium.org

Change-Id: I5e97a339b0f24bc905652c66c52d14263dd8b793
Reviewed-on: https://chromium-review.googlesource.com/769328
Reviewed-by: Antoine Labour <piman@chromium.org>
Commit-Queue: Zhenyao Mo <zmo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516431}
[modify] https://crrev.com/c3c48528bba261dddc1550c3f8c6d3ffa0f4ff5e/ui/compositor/compositor.cc
[modify] https://crrev.com/c3c48528bba261dddc1550c3f8c6d3ffa0f4ff5e/ui/compositor/compositor.h
[modify] https://crrev.com/c3c48528bba261dddc1550c3f8c6d3ffa0f4ff5e/ui/compositor/compositor_unittest.cc

 Issue 783069  has been merged into this issue.

Verified the issue has been fixed on Linux and MacBook Air with Intel HD 4000.