OOPIF compositing violates document lifecycle expectations |
||||
Issue descriptionRepro steps: 1) Go to slashdot 2) Kill all the OOPIFs 3) Scroll down the page [1:1:0206/154500.538904:FATAL:PaintLayerCompositor.cpp(95)] Check failed: layout_view_.Layer()->IsAllowedToQueryCompositingState(). #0 0x55d606ba070c base::debug::StackTrace::StackTrace() #1 0x55d606bc140c logging::LogMessage::~LogMessage() #2 0x55d60aba183b blink::PaintLayerCompositor::InCompositingMode() #3 0x55d60a3e9a65 blink::LocalFrameView::UpdateLifecyclePhasesInternal() #4 0x55d60a3e96a7 blink::LocalFrameView::UpdateAllLifecyclePhases() #5 0x55d60aaa248e blink::PageAnimator::UpdateAllLifecyclePhases() #6 0x55d60a468598 blink::WebViewImpl::UpdateLifecycle() #7 0x55d60b6cecb8 blink::WebViewFrameWidget::UpdateLifecycle() #8 0x55d60b6c3df2 content::RenderWidget::UpdateVisualState() #9 0x55d607ec22bb cc::ProxyMain::BeginMainFrame() #10 0x55d607ecc18f _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIMN2cc9ProxyMainEFvNSt3__110unique_ptrINS4_28BeginMainFrameAndCommitStateENS6_14default_deleteIS8_EEEEENS_7WeakPtrIS5_EEJSB_EEEvOT_OT0_DpOT1_ #11 0x55d607ecc05e _ZN4base8internal7InvokerINS0_9BindStateIMN2cc9ProxyMainEFvNSt3__110unique_ptrINS3_28BeginMainFrameAndCommitStateENS5_14default_deleteIS7_EEEEEJNS_7WeakPtrIS4_EENS0_13PassedWrapperISA_EEEEEFvvEE7RunOnceEPNS0_13BindStateBaseE #12 0x55d606ba1d0a base::debug::TaskAnnotator::RunTask() #13 0x55d6066a14f6 blink::scheduler::internal::ThreadControllerImpl::DoWork() #14 0x55d604aac508 _ZN4base8internal7InvokerINS0_9BindStateIMN7network17ResourceScheduler28ScheduledResourceRequestImplEFvNS3_12_GLOBAL__N_19StartModeEEJNS_7WeakPtrIS5_EES7_EEEFvvEE7RunOnceEPNS0_13BindStateBaseE #15 0x55d606ba1d0a base::debug::TaskAnnotator::RunTask() #16 0x55d606bc9416 base::internal::IncomingTaskQueue::RunTask() #17 0x55d606bc7847 base::MessageLoop::RunTask() #18 0x55d606bc7c64 base::MessageLoop::DeferOrRunPendingTask() #19 0x55d606bc7f28 base::MessageLoop::DoWork() #20 0x55d606bcbae0 base::MessagePumpDefault::Run() #21 0x55d606bc709c base::MessageLoop::Run() #22 0x55d606bf82a6 base::RunLoop::Run() #23 0x55d60b6f4317 content::RendererMain() #24 0x55d6067e6fd5 content::RunZygote() #25 0x55d6067e77b4 content::RunNamedProcessTypeMain() #26 0x55d6067e88d7 content::ContentMainRunnerImpl::Run() #27 0x55d6067f5654 service_manager::Main() #28 0x55d6067e6c21 content::ContentMain() #29 0x55d6046c61cb ChromeMain #30 0x7f3d0ee70f45 __libc_start_main #31 0x55d6046c602a _start
,
Feb 6 2018
This happens occasionally even without my patch FWIW. Maybe less frequently. I believe the problem is we are modifying compositing layers during the layout phase.
,
Feb 7 2018
,
Feb 7 2018
,
Feb 9 2018
What does "kill all the OOPIFs mean?
,
Feb 9 2018
Open the task manager and kill all the processes that render OOPIFs.
,
Feb 10 2018
Can you reproduce this reliably? I can't reproduce it at ToT on Linux with --site-per-process.
,
Feb 10 2018
http://slashdot.org right?
,
Feb 10 2018
Yes. I could reproduce this very reliably. I don't have access to my workstation right now, but I can get back to you on Monday.
,
Feb 12 2018
I was able to repro this without any trouble also. It might be worth mentioning explicitly that it is the main frame's renderer that crashes here, not the OOPIF renderer. When an OOPIF process goes down, the main frame gets a notification and ChildFrameCompositingHelper::ChildFrameGone() adds a layer with a sad face graphic to replace the now-crashed iframe. This crash seems to happen in a subsequent BeginFrame. fsamuel@ (re Comment #2): How would we be modifying compositing layers during layout?
,
Feb 12 2018
This doesn't happen to me as often as before. It's very random now. Now I also get it when the OOPIFs are not killed just by scrolling down the page.
,
Feb 12 2018
OK, seems like a better way to hit this dcheck is just zooming in/out on slashdot.
,
Mar 7 2018
I still can't reproduce. Ctrl-+/- zooming on slashdot.org does not crash for me on this DCHECK.
,
Mar 7 2018
Are you using the --site-per-process flag?
,
Mar 7 2018
Yes.
,
Mar 7 2018
Testing at ToT on Linux.
,
Mar 28 2018
I can now reproduce this bug with a similar stack trace: #3 0x7fac12ebf34a blink::PaintLayer::GetCompositedLayerMapping() #4 0x7fac12ee37df blink::PaintLayerScrollableArea::LayerForScrolling() #5 0x7fac100adecd blink::ScrollableArea::LayerForContainer() #6 0x7fac12e52ad0 blink::TopDocumentRootScrollerController::RootContainerLayer() #7 0x7fac12480e64 blink::WebViewImpl::RegisterViewportLayersWithCompositor() #8 0x7fac12de933e blink::ChromeClientImpl::RegisterViewportLayers() #9 0x7fac12e5265b blink::TopDocumentRootScrollerController::DidUpdateCompositing() #10 0x7fac125586b9 blink::LocalFrameView::UpdateLifecyclePhasesInternal() #11 0x7fac12557b22 blink::LocalFrameView::UpdateAllLifecyclePhases() #12 0x7fac12e1406b blink::PageAnimator::UpdateAllLifecyclePhases() #13 0x7fac12e1991c blink::PageWidgetDelegate::UpdateLifecycle() #14 0x7fac12479fa8 blink::WebViewImpl::UpdateLifecycle() #15 0x7fac125ee1f7 blink::WebViewFrameWidget::UpdateLifecycle() #16 0x7fac21fca416 content::RenderWidget::UpdateVisualState() #17 0x7fac21db6c80 content::RenderWidgetCompositor::UpdateLayerTreeHost() #18 0x7fac1dff3d70 cc::LayerTreeHost::RequestMainFrameUpdate() #19 0x7fac1e0e63bc cc::ProxyMain::BeginMainFrame()
,
Mar 28 2018
The lifecycle is reset to kLayoutClean after compositing is done and before the top-scroller code runs, via calls like this stack trace fragment: #2 0x7f0ad57852b6 blink::PaintLayerCompositor::SetNeedsCompositingUpdate() #3 0x7f0ad56cb5d4 blink::PaintLayer::SetNeedsCompositingInputsUpdateInternal() #4 0x7f0ad56cdbb9 blink::PaintLayer::SetNeedsCompositingInputsUpdate() #5 0x7f0ad497c4ee blink::Element::SetNeedsCompositingUpdate() #6 0x7f0ad4d9ffb8 blink::RemoteFrame::SetWebLayer() #7 0x7f0ad4c66454 blink::WebRemoteFrameImpl::SetWebLayer() #8 0x7f0ae4778baf content::RenderFrameProxy::SetLayer() #9 0x7f0ae45370bd content::ChildFrameCompositingHelper::ChildFrameGone() #10 0x7f0ae47782b3 content::RenderFrameProxy::FrameRectsChanged() #11 0x7f0ad4da12da blink::RemoteFrameClientImpl::FrameRectsChanged() #12 0x7f0ad4da2732 blink::RemoteFrameView::FrameRectsChanged()
,
Mar 28 2018
The stack trace in comment 19 is caused by the CL that is referenced in comment 1, resizing the PictureImageLayer with the sad face graphic during layout. In comment 2 Fady says there were existing ways to hit that, but I don't see any other way that ChildFrameCompositingHelper::ChildFrameGone() can be invoked during layout. Is a simple solution to this just to defer the call to ChildFrameGone()?
,
Mar 28 2018
I think we might be able to move the FrameRectsChanged callback to happen before the compositing step and after layout. That would fix this assert.
,
Mar 30 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/99de1525627bf096c0f0fe85a8cf2c81405a2463 commit 99de1525627bf096c0f0fe85a8cf2c81405a2463 Author: Chris Harrelson <chrishtr@chromium.org> Date: Fri Mar 30 22:50:40 2018 [OOPIF] Move NotifyFrameRectsChangedIfNeededRecursive before compositing The inputs to NotifyFrameRectsChangedIfNeededRecursive only need layout information, not compositing. Also, some of them might want to dirty compositing state due to the change (RemoteFrame in particular). Bug: 809701 Change-Id: Ie029f3eafcbad2af125d6138d1de908561c9ca90 Reviewed-on: https://chromium-review.googlesource.com/986888 Reviewed-by: Stefan Zager <szager@chromium.org> Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#547300} [modify] https://crrev.com/99de1525627bf096c0f0fe85a8cf2c81405a2463/third_party/WebKit/Source/core/frame/LocalFrameView.cpp
,
Mar 31 2018
,
Apr 3 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by samans@chromium.org
, Feb 6 2018