New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 778734 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Aug 14
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

DCHECK failure in ui::ClientGpuMemoryBufferManager::CreateGpuMemoryBuffer() from thread restrictions

Project Member Reported by jamescook@chromium.org, Oct 26 2017

Issue description

ToT on linux desktop, target_os="chromeos"

out/Debug/chrome --ash-host-window-bounds="1280x768" --user-data-dir=/w/udd --ash-dev-shortcuts --ash-debug-shortcuts --use-first-display-as-internal --has-internal-stylus --force-enable-stylus-tools --pen-devices=10 --mus

Tap the stylus icon in the shelf, tap laser pointer, tap on screen.

[9086:9086:1026/105100.347837:FATAL:thread_restrictions.cc(105)] Check failed: !g_base_sync_primitives_disallowed.Get().Get(). Waiting on a //base sync primitive is not allowed on this thread to prevent jank and deadlock. If waiting on a //base sync primitive is unavoidable, do it within the scope of a ScopedAllowBaseSyncPrimitives. If in a test, use ScopedAllowBaseSyncPrimitivesForTesting.
#0 0x7f90bf236fbd base::debug::StackTrace::StackTrace()
#1 0x7f90bf23553c base::debug::StackTrace::StackTrace()
#2 0x7f90bf2b8b2d logging::LogMessage::~LogMessage()
#3 0x7f90bf45b1b4 base::internal::AssertBaseSyncPrimitivesAllowed()
#4 0x7f90bf3e92c3 base::WaitableEvent::TimedWaitUntil()
#5 0x7f90bf3e91f3 base::WaitableEvent::Wait()
#6 0x7f90b5289cfe ui::ClientGpuMemoryBufferManager::CreateGpuMemoryBuffer()
#7 0x7f90b096a557 ash::FastInkView::UpdateBuffer()
#8 0x7f90b096a066 ash::FastInkView::Redraw()
#9 0x7f90b091949f _ZN4base8internal13FunctorTraitsIMN3ash23DisplayAnimatorChromeOSEFvvEvE6InvokeIRKNS_7WeakPtrIS3_EEJEEEvS5_OT_DpOT0_
#10 0x7f90b097550a _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN3ash11FastInkViewEFvvERKNS_7WeakPtrIS5_EEJEEEvOT_OT0_DpOT1_
#11 0x7f90b09754a0 _ZN4base8internal7InvokerINS0_9BindStateIMN3ash11FastInkViewEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE7RunImplIRKS6_RKNSt3__15tupleIJS8_EEEJLm0EEEEvOT_OT0_NSF_16integer_sequenceImJXspT1_EEEE
#12 0x7f90b09753ec _ZN4base8internal7InvokerINS0_9BindStateIMN3ash11FastInkViewEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#13 0x7f90bf1e4e01 _ZNO4base12OnceCallbackIFvvEE3RunEv
#14 0x7f90bf23b900 base::debug::TaskAnnotator::RunTask()

Maybe it just needs a base::ThreadRestrictions::ScopedAllowWait similar to ServerGpuMemoryBufferManager? I don't understand the code well enough to know if this is safe.

 

Comment 1 by sadrul@chromium.org, Nov 20 2017

Cc: reve...@chromium.org
+reveman@: should this actuallly block (blocking UI does not seem like a great thing to do)? Or should this rather wait for the memory to be allocated asynchronously before it uses it?
CreateGpuMemoryBuffer is typically used on raster worker thread so it's not a huge problem but in the fast ink case it would maybe be worth removing this. FYI, we have the same blocking calls in buffer queue code.
Components: -Internals>MUS Internals>Services>WindowService
Labels: -Proj-Mustash-Mus Proj-Mustash
Migrating Proj-Mustash-Mus to components Internals>Services>WindowService and Internals>Services>Ash

Status: WontFix (was: Assigned)
Obsolete. We don't have --mus anymore. Laser pointer doesn't seem to work in mash, but that's a separate issue.

Sign in to add a comment