On Mac, killing GPU process from task manager triggers a DCHECK |
|||
Issue description[2425:775:1110/121246.212273:FATAL:context_provider_command_buffer.cc(436)] Check failed: context_thread_checker_.CalledOnValidThread(). 0 Chromium Framework 0x000000010869c4cc base::debug::StackTrace::StackTrace(unsigned long) + 28 1 Chromium Framework 0x00000001086bcd32 logging::LogMessage::~LogMessage() + 210 2 Chromium Framework 0x00000001070898a0 ui::ContextProviderCommandBuffer::OnLostContext() + 96 3 Chromium Framework 0x0000000109a706e8 gpu::gles2::GLES2Implementation::OnGpuControlLostContext() + 200 4 Chromium Framework 0x0000000106376c48 gpu::CommandBufferProxyImpl::DisconnectChannel() + 408 5 Chromium Framework 0x0000000106378658 gpu::CommandBufferProxyImpl::OnGpuAsyncMessageError(gpu::error::ContextLostReason, gpu::error::Error) + 184 6 Chromium Framework 0x0000000106378725 gpu::CommandBufferProxyImpl::OnChannelError() + 149 7 Chromium Framework 0x0000000106381a17 base::internal::Invoker<base::internal::BindState<void (IPC::Listener::*)(), base::WeakPtr<IPC::Listener> >, void ()>::Run(base::internal::BindStateBase*) + 183 8 Chromium Framework 0x000000010869cd05 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) + 261 9 Chromium Framework 0x00000001080189ae blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue(blink::scheduler::internal::WorkQueue*, bool, blink::scheduler::LazyNow, base::TimeTicks*) + 1438 10 Chromium Framework 0x000000010801617d blink::scheduler::TaskQueueManager::DoWork(bool) + 1069 11 Chromium Framework 0x000000010801b02c base::internal::Invoker<base::internal::BindState<void (blink::scheduler::TaskQueueManager::*)(bool), base::WeakPtr<blink::scheduler::TaskQueueManager>, bool>, void ()>::Run(base::internal::BindStateBase*) + 188 12 Chromium Framework 0x000000010869cd05 base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*) + 261 13 Chromium Framework 0x00000001086d03e9 base::internal::IncomingTaskQueue::RunTask(base::PendingTask*) + 121 14 Chromium Framework 0x00000001086d4607 base::MessageLoop::RunTask(base::PendingTask*) + 551 15 Chromium Framework 0x00000001086d499a base::MessageLoop::DeferOrRunPendingTask(base::PendingTask) + 202 16 Chromium Framework 0x00000001086d4c36 base::MessageLoop::DoWork() + 614 17 Chromium Framework 0x00000001086d7c6a base::MessagePumpCFRunLoopBase::RunWork() + 42 18 Chromium Framework 0x00000001086be9ea base::mac::CallWithEHFrame(void () block_pointer) + 10 19 Chromium Framework 0x00000001086d758f base::MessagePumpCFRunLoopBase::RunWorkSource(void*) + 63 20 CoreFoundation 0x00007fff9a17f321 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 21 CoreFoundation 0x00007fff9a16021d __CFRunLoopDoSources0 + 557 22 CoreFoundation 0x00007fff9a15f716 __CFRunLoopRun + 934 23 CoreFoundation 0x00007fff9a15f114 CFRunLoopRunSpecific + 420 24 Foundation 0x00007fff9bb72252 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 277 25 Chromium Framework 0x00000001086d82ce base::MessagePumpNSRunLoop::DoRun(base::MessagePump::Delegate*) + 126 26 Chromium Framework 0x00000001086d70ae base::MessagePumpCFRunLoopBase::Run(base::MessagePump::Delegate*) + 110 27 Chromium Framework 0x00000001086d3f39 base::MessageLoop::Run(bool) + 169 28 Chromium Framework 0x0000000108706978 base::RunLoop::Run() + 248 29 Chromium Framework 0x000000010d805356 content::RendererMain(content::MainFunctionParams const&) + 886 30 Chromium Framework 0x0000000108187a74 content::ContentMainRunnerImpl::Run() + 564 31 Chromium Framework 0x0000000109ea86c2 service_manager::Main(service_manager::MainParams const&) + 2482 32 Chromium Framework 0x0000000108186e34 content::ContentMain(content::ContentMainParams const&) + 68 33 Chromium Framework 0x0000000105fba76f ChromeMain + 175 34 Chromium Helper 0x00000001053314ac main + 1788 35 libdyld.dylib 0x00007fffaf8e7235 start + 1 36 ??? 0x0000000000000017 0x0 + 23
,
Nov 10 2017
What thread is CommandBufferProxyImpl::OnChannelError on?
,
Nov 10 2017
That's the renderer main thread (RendererMain is in the stack)
,
Nov 10 2017
Mmh, I think the thread checking in ContextProviderCommandBuffer may be wrong/insufficient wrt ScopedContextLock. For the raster worker context, ScopedContextLock calls ContextProviderCommandBuffer::DetachFromThread as it switches between active threads (e.g. raster worker vs main thread), however the callbacks will always called on the main thread, and while the actual lock is taken (in CommandBufferProxyImpl::OnChannelError), nothing detaches the ContextProviderCommandBuffer in that path, and so the thread check fails if the last ScopedContextLock was taken on the worker thread
,
Nov 10 2017
piman's right. When we disable gpu rasterization, the dcheck is no longer triggered. When the dcheck is triggered, the context_thread_check_'s thread_id_ is 0.
,
Nov 10 2017
I'm not actually sure why we DetachFromThread when we take the ScopedContextLock. It seems to me that if we have a lock (thread-safe mode), we should rely on lock_->AssertLocked() (which checks that the current thread is the one that took the lock), and otherwise (single-thread mode) we should check the thread.
,
Nov 11 2017
https://chromium-review.googlesource.com/c/chromium/src/+/765192 should fix this
,
Nov 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/2bbf61df6e8ebc09c19d30fff37fb19e19699c20 commit 2bbf61df6e8ebc09c19d30fff37fb19e19699c20 Author: Antoine Labour <piman@chromium.org> Date: Tue Nov 14 21:41:17 2017 ContextProvider: correctly assert either lock or thread Before this CL we rely on the ScopedContextLock to bounce the ContextProvider's thread checker between threads. This only works provided ScopedContextLock is in the path, which is not the case for e.g. the lost context callback. Instead, assert that the lock is held by the current thread (if thread-aware ContextProvider) or that we are on the correct thread (if single-thread). Bug: 783915 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: If386b6998ca59dae2908a756dd53cef04a3ed5b0 Reviewed-on: https://chromium-review.googlesource.com/765192 Commit-Queue: Antoine Labour <piman@chromium.org> Reviewed-by: danakj <danakj@chromium.org> Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org> Cr-Commit-Position: refs/heads/master@{#516439} [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/cc/raster/raster_buffer_provider_unittest.cc [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/cc/test/test_context_provider.cc [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/cc/test/test_context_provider.h [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/cc/tiles/gpu_image_decode_cache_unittest.cc [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/cc/trees/layer_tree_host_unittest.cc [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/components/viz/common/gpu/context_provider.cc [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/services/ui/public/cpp/gpu/context_provider_command_buffer.cc [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/services/ui/public/cpp/gpu/context_provider_command_buffer.h [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/ui/compositor/test/in_process_context_factory.cc [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/ui/compositor/test/in_process_context_provider.cc [modify] https://crrev.com/2bbf61df6e8ebc09c19d30fff37fb19e19699c20/ui/compositor/test/in_process_context_provider.h
,
Nov 14 2017
Should be fixed. |
|||
►
Sign in to add a comment |
|||
Comment 1 by zmo@chromium.org
, Nov 10 2017