Ahh OK, those are surface invariants violations then...there are cases a device scale factor change or resize is happening and we're not allocating a new LocalSurfaceId!
It looks like CommandBufferProxyImpl::Send() calls GpuChannelHost::Send(), which has a call to WaitableEvent::Wait() in it. WaitableEvent::Wait() DCHECKs on success. I assume the wait is failing because the other end (gpu) is crashing. If that is in fact the cause, then it seems CommandBufferProxyImpl shouldn't use Wait(). Instead CommandBufferProxyImpl should use Wait() with an infinite timeout and deal with a false return. Does that sound right?
To be honest, I don't understand the GPU crashes. sadrul@ or kylechar@ might? It's really hard to tell from the call stack. Passing to sadrul@ for thoughts.
> I assume the wait is failing because the other end (gpu) is crashing.
The crash seems to always happen in pthread_cond_wait(). I don't think that necessarily means the gpu process has crashed? Is the gpu-process crashing that often anyway?
It is possible that MusContextFactory is doing something wrong (MusContextFactory::CreateLayerTreeFrameSink() is always in the callstack). I started looking at that, but haven't gone very far unfortunately.
I don't see very many GPU-related crashes in tap_visualizer or shortcut_viewer in M70 and M71. See links in the original description.
Maybe something got fixed? Are other processes crashing?
Comment 1 by sky@chromium.org
, Jul 10