Mustash: DCHECK failure in FATAL:surface_manager.cc( |
||||||||
Issue descriptionReproducible in chrome --mash on Ubuntu by opening the app list, closing it, and then opening it again. [17287:17302:0210/114335.470943:684467890026:FATAL:surface_manager.cc(507)] Check failed: children[i] != child_frame_sink_id. #0 0x7f65c653dac1 __interceptor_backtrace #1 0x7f65c417210c base::debug::StackTrace::StackTrace() #2 0x7f65c41e879e logging::LogMessage::~LogMessage() #3 0x7f65b63727a8 cc::SurfaceManager::RegisterFrameSinkHierarchy() #4 0x7f65a6ff9f6a cc::mojom::MojoCompositorFrameSinkPrivateStubDispatch::Accept() #5 0x7f65c4789923 mojo::InterfaceEndpointClient::HandleValidatedMessage() #6 0x7f65c4787f08 mojo::FilterChain::Accept() #7 0x7f65c478d9d8 mojo::InterfaceEndpointClient::HandleIncomingMessage() #8 0x7f65c47ad749 mojo::internal::MultiplexRouter::ProcessIncomingMessage() #9 0x7f65c47ac078 mojo::internal::MultiplexRouter::Accept() #10 0x7f65c4787f08 mojo::FilterChain::Accept() #11 0x7f65c47796e3 mojo::Connector::ReadSingleMessage() #12 0x7f65c477ab5b mojo::Connector::OnHandleReadyInternal() #13 0x7f65c473f4d8 mojo::Watcher::OnHandleReady() #14 0x7f65c473f931 _ZN4base8internal13FunctorTraitsIMN4mojo7WatcherEFvjEvE6InvokeIRKNS_7WeakPtrIS3_EEJRKjEEEvS5_OT_DpOT0_ #15 0x7f65c417444f base::debug::TaskAnnotator::RunTask() #16 0x7f65c421b87a base::MessageLoop::RunTask() #17 0x7f65c421df80 base::MessageLoop::DoWork() #18 0x7f65c42277a3 base::MessagePumpDefault::Run() #19 0x7f65c421af17 base::MessageLoop::RunHandler() #20 0x7f65c42de240 base::RunLoop::Run() #21 0x7f65c43b09a0 base::Thread::Run() #22 0x7f65c43b1a4f base::Thread::ThreadMain() #23 0x7f65c4394423 base::(anonymous namespace)::ThreadFunc() #24 0x7f65a587f184 start_thread #25 0x7f65a426a37d clone
,
Feb 10 2017
There are two problems here. First, we are never calling SurfaceFactory::UnregisterFrameSinkHierachy() when we destroy a CompositorFrameSink. We recreate a CompositorFrameSink with the same FrameSinkId and try to register it a second time. That hits the DCHECK above. The second problem is there are two ServerWindows that correspond to MojoCompositorFrameSinks. Only one of the ServerWindows ever gets destroyed and the second one is just orphaned off screen. The same FrameSinkId gets reused which causes more problems even if we do cleanup correctly. The fact that the orphaned ServerWindow stays alive forever is also a bug but might be because the app list is hosted by Chrome.
,
Feb 14 2017
The second problem isn't actually a problem, at least in terms of cleaning up the FrameSinkId hierarchy. As long as we unregister the FrameSinkId correctly when unparenting ServerWindows SurfaceManager state will be correct. It might be a bug that the ServerWindow stays around despite not being displayed but that is separate issue.
,
Feb 14 2017
Issue 673030 has been merged into this issue.
,
Feb 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/509840116ed907fb1e466c7ca0a35eb76f0eb6d5 commit 509840116ed907fb1e466c7ca0a35eb76f0eb6d5 Author: kylechar <kylechar@chromium.org> Date: Tue Feb 14 19:13:37 2017 Remove FrameSinkId hierarchy when unparenting ServerWindow. We need to change the FrameSinkId heirarchy along with ServerWindow hierarchy. We were missing a case when we unparent a ServerWindow. This caused a crash in app list because we never unregister the FrameSinkId heirarchy. There is a DCHECK that we don't register the same hierarchy twice and when reopening the app list that DCHECK was hit. BUG= 690970 Review-Url: https://codereview.chromium.org/2692223003 Cr-Commit-Position: refs/heads/master@{#450427} [modify] https://crrev.com/509840116ed907fb1e466c7ca0a35eb76f0eb6d5/services/ui/ws/server_window.cc
,
Feb 16 2017
For the ServerWindow that doesn't get destroyed I've filed https://bugs.chromium.org/p/chromium/issues/detail?id=693194. Otherwise this is fixed.
,
Apr 17 2017
,
May 30 2017
,
Aug 1 2017
,
Oct 14 2017
,
Feb 26 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by kylec...@chromium.org
, Feb 10 2017