DCHECK on chrome mash shutdown in GPU SurfaceManager |
|||||||
Issue descriptionI'm having problems with chrome shutdown on device. I noticed this happens on linux desktop: Run chrome --mash kill -SIGTERM <root-process-id> (This simulates how session_manager shuts down chrome on device) DCHECK failure: [30844:30868:0228/101236.564125:94279776300:FATAL:surface_manager.cc(67)] Check failed: frame_sink_source_map_.size() == 0u (16 vs. 0) #0 0x7f0ab7e64cf7 base::debug::StackTrace::StackTrace() #1 0x7f0ab7e8684a logging::LogMessage::~LogMessage() #2 0x7f0ab41d6343 cc::SurfaceManager::~SurfaceManager() #3 0x7f0ab9327e62 ui::DisplayCompositor::~DisplayCompositor() #4 0x7f0ab9327ea9 ui::DisplayCompositor::~DisplayCompositor() #5 0x7f0ab933811f ui::GpuMain::TearDownOnCompositorThread() #6 0x7f0ab7e657b9 base::debug::TaskAnnotator::RunTask() #7 0x7f0ab7e9356d base::MessageLoop::RunTask() #8 0x7f0ab7e93c35 base::MessageLoop::DoWork() #9 0x7f0ab7e95459 base::MessagePumpDefault::Run() #10 0x7f0ab7e932ea base::MessageLoop::RunHandler() #11 0x7f0ab7ec61ef base::RunLoop::Run() #12 0x7f0ab7f063cb base::Thread::Run() #13 0x7f0ab7f0687e base::Thread::ThreadMain() #14 0x7f0ab7efe71c base::(anonymous namespace)::ThreadFunc() #15 0x7f0ab7fdd184 start_thread #16 0x7f0aaee2037d clone https://cs.chromium.org/chromium/src/cc/surfaces/surface_manager.cc?q=surface_manager.cc&sq=package:chromium&dr&l=67 fsamuel, who would be a good person to look at this?
,
Mar 1 2017
I'm also seeing this when looking into views_mus_unittests
,
Mar 1 2017
,
Mar 3 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/462ef8c3894d3dc1eceb4a2327006b372737f749 commit 462ef8c3894d3dc1eceb4a2327006b372737f749 Author: fsamuel <fsamuel@chromium.org> Date: Fri Mar 03 19:12:11 2017 Decouple FrameSink Hierarchy registration from SurfaceFactoryClient Prior to this patch, FrameSink hierarchy registration and SurfaceFactoryClient registration were tightly coupled in SurfaceManager. In SurfaceManager's destructor, it verified that the frame_sink_source_map_ is empty. This proved problematic in Mus+Ash because the Mus window server tries to unregister the framesink hierarchy at shutdown by issuing IPCs to Mus-GPU. Thus, there is no guarantee these IPCs will arrive in the gpu process prior to SurfaceManager destruction. By design, Mojo provides no guarantees on process shutdown order, and even if a process tries to override the behavior, Mojo may someday decide to force quit processes and so we cannot guarantee Mus-WS will outlive Mus-GPU. Currently, in Mus+Ash, the BeginFrame hierarchy can be much larger than the set of FrameSinkIds with an associated SurfaceFactoryClient (an associated CompositorFrameSink), in order to facilitate reparenting windows in an environment where not all windows submit CompositorFrames (a single client may embed only a single CompositorFrame that embeds a bunch of local window concepts for performance reasons). It seems to make sense to decouple the BeginFrame hierarchy from the SurfaceFactoryClient hierarchy, in that case. Furthermore, the DCHECK in the SurfaceManager destructor exists to verify that there are no lingering clients and we haven't been wastefully ticking BeginFrames. By decoupling client registration and BeginFrame registration, we can continue to guard against that potential bug while allowing Mus+Ash to have a clean shutdown. BUG= 697116 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2731743002 Cr-Commit-Position: refs/heads/master@{#454641} [modify] https://crrev.com/462ef8c3894d3dc1eceb4a2327006b372737f749/cc/surfaces/surface_manager.cc [modify] https://crrev.com/462ef8c3894d3dc1eceb4a2327006b372737f749/cc/surfaces/surface_manager.h [modify] https://crrev.com/462ef8c3894d3dc1eceb4a2327006b372737f749/cc/surfaces/surface_manager_unittest.cc
,
Mar 21 2017
,
May 30 2017
,
Aug 1 2017
,
Jan 22 2018
,
Feb 26 2018
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by fsam...@chromium.org
, Feb 28 2017