AsyncLayerTreeFrameSink::SubmitCompositorFrame Crash |
||
Issue descriptionOS: Seen on Windows, can occur on others. Version: 70.0.3538.102 It appears that it is possible for LayerTreeHostImpl::DrawLayers to attempt to submit compositor frames to a AsyncLayerTreeFrameSink which has been detached, and nulled out. async_layer_tree_frame_sink.cc:176 cc::mojo_embedder::AsyncLayerTreeFrameSink::SubmitCompositorFrame(viz::CompositorFrame) layer_tree_host_impl.cc:2047 cc::LayerTreeHostImpl::DrawLayers(cc::LayerTreeHostImpl::FrameData *) proxy_impl.cc:670 cc::ProxyImpl::DrawInternal(bool) proxy_impl.cc:534 cc::ProxyImpl::ScheduledActionDrawIfPossible() scheduler.cc:703 cc::Scheduler::DrawIfPossible() scheduler.cc:804 cc::Scheduler::ProcessScheduledActions() scheduler.cc:691 cc::Scheduler::OnBeginImplFrameDeadline() cancelable_callback.h:126 base::internal::CancelableCallbackImpl<base::OnceCallback<void ()> >::ForwardOnce<> Low rate of incidents but worth fixing: https://crash.corp.google.com/browse?q=stable_signature%3D%27cc%3A%3Amojo_embedder%3A%3AAsyncLayerTreeFrameSink%3A%3ASubmitCompositorFrame-48eb9255%27+AND+stable_signature%3D%27cc%3A%3Amojo_embedder%3A%3AAsyncLayerTreeFrameSink%3A%3ASubmitCompositorFrame-48eb9255%27#samplereports
,
Nov 20
I had put together a patch with a suspected fix: https://chromium-review.googlesource.com/c/chromium/src/+/1340794 However danakj@ suggested that I update cc::Scheduler directly when we lose the LayerTreeFrameSink. Further research shows that we already do that. When digging through more crash stacks I found: - cc::SchedulerStateMachine shows the LayerTreeFrameSink set to NONE - cc::ProxyImpl::DrawInternal is being called with forced==true, which shouldn't occur from ScheduledActionDrawIfPossible One comment mentioned seeing this crash upon resuming from suspend. With most reports also showing a process uptime of only a few seconds. I'm beginning to suspect some form of memory corruption while suspended.
,
Nov 28
It was suggested by danakj@ that we were potentially bypassing the LayerTreeFrameSink::NONE checks in SchedulerStateMachine::ShouldDraw. As these return active_tree_needs_first_draw_ as the result for drawing. However looking at the dumps, that is set to false. There's also a further check in SchedulerStateMachine::NextAction which would lead to DRAW_ABORT instead of DRAW_IF_POSSIBLE. So these leaves me with the supposition of memory corruption, as the stack seen should not be reached based on the actual state of the Scheduler. Which if the case, we'd eventually crash from memory corruption anyways. So trying to mitigate would just delay the crash. I'll mark this as Won't Fix. |
||
►
Sign in to add a comment |
||
Comment 1 by danakj@chromium.org
, Nov 16