SkiaRenderer + DDL crashes with chrome:://welcome page |
|||
Issue description
Command line for SkiaRenderer + DDL is:
out/Release/chrome --user-data-dir=/tmp/penghuang-mustash \
--enable-features=VizDisplayCompositor,UseSkiaRenderer,UseSkiaDeferredDisplayList \
--use-gl=any \
--enable-oop-rasterization \
--enable-gpu-rasterization \
--enable-raster-to-sk-image \
--no-sandbox
The crash stack is:
[86421:86567:1119/125710.656710:ERROR:GrDrawingManager.cpp(525)] ../../third_party/skia/src/gpu/GrDrawingManager.cpp:525: fatal error: "assert(!fActiveOpList->isClosed())"
Received signal 6
#0 0x7f0c2f134a8f base::debug::StackTrace::StackTrace()
#1 0x7f0c2f134571 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#2 0x7f0c22cca0c0 <unknown>
#3 0x7f0c20b5afcf gsignal
#4 0x7f0c20b5c3fa abort
#5 0x7f0c2e8f5275 sk_abort_no_print()
#6 0x7f0c2e97274f GrDrawingManager::validate()
#7 0x7f0c2e9738d5 GrDrawingManager::newRTOpList()
#8 0x7f0c2e997331 GrRenderTargetContext::getRTOpList()
#9 0x7f0c2e997a8b GrRenderTargetContext::discard()
#10 0x7f0c2e96bb0e GrContextPriv::makeDeferredRenderTargetContext()
#11 0x7f0c2ed11cb6 SkSpecialSurface::MakeRenderTarget()
#12 0x7f0c2ed10f94 SkSpecialImage_Gpu::onMakeSurface()
#13 0x7f0c2ed0faef SkSpecialImage::makeSurface()
#14 0x7f0c2edbe3af SkColorFilterImageFilter::onFilterImage()
#15 0x7f0c2ec6c8f6 SkImageFilter::filterImage()
#16 0x7f0c2ec6e23e SkImageFilter::filterInput()
#17 0x7f0c2ec73720 SkLocalMatrixImageFilter::onFilterImage()
#18 0x7f0c2ec6c8f6 SkImageFilter::filterImage()
#19 0x7f0c2ed2b3a8 SkImage::makeWithFilter()
#20 0x7f0c2b18905d viz::SkiaHelper::ApplyImageFilter()
#21 0x7f0c1f36bf13 viz::SkiaRenderer::CalculateRPDQParams()
#22 0x7f0c1f36c3ac viz::SkiaRenderer::DrawRenderPassQuadInternal()
#23 0x7f0c1f36a81e viz::SkiaRenderer::DrawRenderPassQuad()
#24 0x7f0c1f369108 viz::SkiaRenderer::DoDrawQuad()
#25 0x7f0c1f32733f viz::DirectRenderer::DrawRenderPass()
#26 0x7f0c1f32637b viz::DirectRenderer::DrawRenderPassAndExecuteCopyRequests()
#27 0x7f0c1f325b74 viz::DirectRenderer::DrawFrame()
#28 0x7f0c1f32c1a2 viz::Display::DrawAndSwap()
#29 0x7f0c1f33b7f2 viz::DisplayScheduler::DrawAndSwap()
#30 0x7f0c1f33af73 viz::DisplayScheduler::AttemptDrawAndSwap()
#31 0x7f0c1f33a7cc viz::DisplayScheduler::OnBeginFrameDeadline()
#32 0x7f0c1f33d514 _ZN4base8internal7InvokerINS0_9BindStateIMN3viz16DisplaySchedulerEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#33 0x7f0c1f33db3c _ZN4base8internal22CancelableCallbackImplINS_17RepeatingCallbackIFvvEEEE16ForwardRepeatingIJEEEvDpT_
#34 0x7f0c1f33d514 _ZN4base8internal7InvokerINS0_9BindStateIMN3viz16DisplaySchedulerEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE
#35 0x7f0c2f039be9 base::debug::TaskAnnotator::RunTask()
#36 0x7f0c2f0688bf base::MessageLoopImpl::RunTask()
#37 0x7f0c2f069042 base::MessageLoopImpl::DoWork()
#38 0x7f0c2f06b146 base::MessagePumpDefault::Run()
#39 0x7f0c2f068395 base::MessageLoopImpl::Run()
#40 0x7f0c2f09ba36 base::RunLoop::Run()
#41 0x7f0c2f0fcffa base::Thread::Run()
#42 0x7f0c2f0fd5b8 base::Thread::ThreadMain()
#43 0x7f0c2f14b6c8 base::(anonymous namespace)::ThreadFunc()
#44 0x7f0c22cc0494 start_thread
#45 0x7f0c20c10a8f clone
r8: 0000000000000000 r9: 00007f0c0cf72770 r10: 0000000000000008 r11: 0000000000000246
r12: 0000288bb7808bd0 r13: 0000288bb866ab40 r14: 0000288bb776e700 r15: 00007f0c0cf72a78
di: 0000000000000002 si: 00007f0c0cf72770 bp: 00007f0c0cf729b0 bx: 0000000000000006
dx: 0000000000000000 ax: 0000000000000000 cx: 00007f0c20b5afcf sp: 00007f0c0cf727e8
ip: 00007f0c20b5afcf efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000
trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.
,
Nov 19
Okay so the investigation so far seems to suggest that we have two different DDL contexts and we are trying to draw an image from one DDL context into the other one. This is tripping up our system since GrSurfaceProxies have a lot of state that is connected to the context they were created on. So when we try to draw into another DDL context we start hitting asserts. @penghuang, do you know if viz/SkiaRenderer is ever in a case where it would have two DDLRecorders active on the same thread? And if so how are they sharing an SkImage?
,
Nov 22
,
Nov 22
I found the problem in chrome. Thanks for the hint.
,
Nov 23
,
Nov 23
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/94c1fb49f1e8db63942bd1b4f99be75e3f716a62 commit 94c1fb49f1e8db63942bd1b4f99be75e3f716a62 Author: Peng Huang <penghuang@chromium.org> Date: Fri Nov 23 17:04:11 2018 SkiaRenderer: Use the correct DDL recorder to create SkImage Bug: 906688 Change-Id: If53d2ad9420440a5b9cb214b2c23fd64168187b9 Reviewed-on: https://chromium-review.googlesource.com/c/1348862 Reviewed-by: weiliangc <weiliangc@chromium.org> Commit-Queue: Peng Huang <penghuang@chromium.org> Cr-Commit-Position: refs/heads/master@{#610638} [modify] https://crrev.com/94c1fb49f1e8db63942bd1b4f99be75e3f716a62/components/viz/service/display_embedder/skia_output_surface_impl.cc [modify] https://crrev.com/94c1fb49f1e8db63942bd1b4f99be75e3f716a62/components/viz/service/display_embedder/skia_output_surface_impl.h |
|||
►
Sign in to add a comment |
|||
Comment 1 by penghuang@chromium.org
, Nov 19