Hitting assert blink::LayoutObject::assertLaidOut in eng builds |
||||||||||
Issue descriptionWe found this on Chromecast, but it also reproduces on a recent eng build of Chromium. To repro, load https://cdn.getvideostream.com/chromecast-receiver-24/cast.html From a quick search, it sounds like it might be the same as issue 590856 - but that bug is huge and hard to follow, so I'm not 100% sure :) Callstack and some debug logging below: LayoutView 0x38d643204010 #document 0x2cd6cde24e0 LayoutBlockFlow 0x38d643224010 HTML 0x2cd6cde30b8 LayoutBlockFlow 0x38d643224128 BODY 0x2cd6cde3d28 LayoutBlockFlow (positioned) 0x38d643224240 DIV 0x2cd6cde3de0 CLASS="cast-wrapper" LayoutBlockFlow (positioned) 0x38d643224358 DIV 0x2cd6cde3e98 ID="splash-view" CLASS="splash-view visible" LayoutBlockFlow (positioned) 0x38d643224470 DIV 0x2cd6cde3f50 ID="splash-images" CLASS="image-container show-1" LayoutImage (positioned) 0x38d64322c010 IMG 0x2cd6cde4008 LayoutVideo (positioned) 0x38d643230010 VIDEO 0x2cd6cde52b0 ID="video" * LayoutBlockFlow (positioned) 0x38d64323c010 DIV 0x2cd6cdea490 STYLE="font-size: 26px;" LayoutFlexibleBox (relative positioned) 0x38d643248010 DIV 0x2cd6cde5890 LayoutFlexibleBox (relative positioned) 0x38d6432481c8 DIV 0x2cd6cde5a58 LayoutBlockFlow 0x38d643224588 DIV 0x2cd6cde5d98 LayoutFlexibleBox (positioned) 0x38d643248380 DIV 0x2cd6cde9240 CLASS="loading-chip-wrapper" LayoutBlockFlow 0x38d6432246a0 DIV 0x2cd6cde92f8 ID="loading-chip" CLASS="loading-chip-square" LayoutImage 0x38d64322c118 IMG 0x2cd6cde93b0 LayoutText 0x38d643258010 #text 0x2cd6cde9478 "\n " LayoutFlexibleBox (positioned) 0x38d643248538 DIV 0x2cd6cde9568 CLASS="loading-chip-wrapper" LayoutFlexibleBox (positioned) 0x38d6432486f0 DIV 0x2cd6cde9c00 CLASS="loading-chip-wrapper" LayoutFlexibleBox (positioned) 0x38d6432488a8 DIV 0x2cd6cdea298 ID="toast-view" CLASS="toast-view" Received signal 11 SEGV_MAPERR 0000fbadbeef #0 0x7f77756dec6e base::debug::StackTrace::StackTrace() #1 0x7f77756de7af base::debug::(anonymous namespace)::StackDumpSignalHandler() #2 0x7f776ba8c330 <unknown> #3 0x7f777b5c7145 blink::LayoutObject::assertLaidOut() #4 0x7f777b5c5a78 blink::LayoutObject::assertSubtreeIsLaidOut() #5 0x7f777b5b2739 blink::FrameView::layout() #6 0x7f777ade3355 blink::Document::implicitClose() #7 0x7f777b765313 blink::FrameLoader::checkCompleted() #8 0x7f777b75e43a blink::FrameFetchContext::didLoadResource() #9 0x7f777b5733d1 blink::ResourceFetcher::didFinishLoading() #10 0x7f777b584922 blink::ResourceLoader::didFinishLoading() #11 0x7f777a4dcac5 content::WebURLLoaderImpl::Context::OnCompletedRequest() #12 0x7f777a4dd1c7 content::WebURLLoaderImpl::RequestPeerImpl::OnCompletedRequest() #13 0x7f777a4ba694 content::ResourceDispatcher::OnRequestComplete() #14 0x7f777a4c23d2 _ZN4base20DispatchToMethodImplIPN7content18ResourceDispatcherEMS2_FviRKNS1_31ResourceRequestCompletionStatusEEJiS4_EJLm0ELm1EEEEvRKT_T0_RKSt5tupleIJDpT1_EENS_13IndexSequenceIJXspT2_EEEE #15 0x7f777a4c2315 _ZN4base16DispatchToMethodIPN7content18ResourceDispatcherEMS2_FviRKNS1_31ResourceRequestCompletionStatusEEJiS4_EEEvRKT_T0_RKSt5tupleIJDpT1_EE #16 0x7f777a4c22bf _ZN3IPC16DispatchToMethodIN7content18ResourceDispatcherEMS2_FviRKNS1_31ResourceRequestCompletionStatusEEvSt5tupleIJiS3_EEEEvPT_T0_PT1_RKT2_ #17 0x7f777a4bec31 _ZN3IPC8MessageTI32ResourceMsg_RequestComplete_MetaSt5tupleIJiN7content31ResourceRequestCompletionStatusEEEvE8DispatchINS3_18ResourceDispatcherES8_vMS8_FviRKS4_EEEbPKNS_7MessageEPT_PT0_PT1_T2_ #18 0x7f777a4b7eab content::ResourceDispatcher::DispatchMessage() #19 0x7f777a4b71f9 content::ResourceDispatcher::OnMessageReceived() #20 0x7f777a4c3da5 content::ResourceSchedulingFilter::DispatchMessage() #21 0x7f777a4c402a content::(anonymous namespace)::DispatchMessageTask::run() #22 0x7f777a54f05e scheduler::WebTaskRunnerImpl::runTask() #23 0x7f777a54ff97 _ZN4base8internal13FunctorTraitsIPFvSt10unique_ptrIN5blink13WebTaskRunner4TaskESt14default_deleteIS5_EEEvE6InvokeIJS8_EEEvSA_DpOT_ #24 0x7f777a54ff08 _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKPFvSt10unique_ptrIN5blink13WebTaskRunner4TaskESt14default_deleteIS7_EEEJSA_EEEvOT_DpOT0_ #25 0x7f777a54feb7 _ZN4base8internal7InvokerINS0_9BindStateIPFvSt10unique_ptrIN5blink13WebTaskRunner4TaskESt14default_deleteIS6_EEEJNS0_13PassedWrapperIS9_EEEEEFvvEE7RunImplIRKSB_RKSt5tupleIJSD_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE #26 0x7f777a54fc8c _ZN4base8internal7InvokerINS0_9BindStateIPFvSt10unique_ptrIN5blink13WebTaskRunner4TaskESt14default_deleteIS6_EEEJNS0_13PassedWrapperIS9_EEEEEFvvEE3RunEPNS0_13BindStateBaseE #27 0x7f777140c48e base::Callback<>::Run() #28 0x7f77758a655e base::debug::TaskAnnotator::RunTask() #29 0x7f777a553424 scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() #30 0x7f777a5511f5 scheduler::TaskQueueManager::DoWork() #31 0x7f777a557b08 _ZN4base8internal13FunctorTraitsIMN9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEvE6InvokeIRKNS_7WeakPtrIS3_EEJRKS4_RKbEEEvS6_OT_DpOT0_ #32 0x7f777a557a04 _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbERKNS_7WeakPtrIS5_EEJRKS6_RKbEEEvOT_OT0_DpOT1_ #33 0x7f777a557964 _ZN4base8internal7InvokerINS0_9BindStateIMN9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS4_EES5_bEEEFvvEE7RunImplIRKS7_RKSt5tupleIJS9_S5_bEEJLm0ELm1ELm2EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE
,
Aug 25 2016
Thanks, that was my suspicion. That bug is *huge*, is there a TL;DR of current status? Is it waiting for layout team to take another look now?
,
Aug 25 2016
That bug is all about what the crash reports are and how we guessed and debugged the problems. It's unlikely that we'll fix the bug directly there. Its blocking bugs (including this one) are actually more meaningful because they are specific cases mostly having reproducing methods. Hopefully after we fix all (current and future) blocking bugs one by one we'll eventually eliminate all crash reports and close that bug.
,
Aug 25 2016
,
Aug 25 2016
,
Aug 25 2016
The problem occurs when a child of LayoutVideo is set position:fixed. The child is marked selfNeedsLayout, and LayoutView is marked posChildNeedsLayout(), but the child is not put in LayoutView's positionedObjects() set, causing that it is not reached during layout.
LayoutView 0x32829f004010 #document 0x3a66b5282770
LayoutBlockFlow 0x32829f018010 HTML 0x3a66b5283550
LayoutBlockFlow 0x32829f018130 BODY 0x3a66b52846f8
LayoutBlockFlow (positioned) 0x32829f018250 DIV 0x3a66b5284808 CLASS="cast-wrapper"
LayoutBlockFlow (positioned) 0x32829f018370 DIV 0x3a66b5284918 ID="splash-view" CLASS="splash-view visible"
LayoutBlockFlow (positioned) 0x32829f018490 DIV 0x3a66b5284a28 ID="splash-images" CLASS="image-container show-1"
LayoutImage (positioned) 0x32829f024010 IMG 0x3a66b5284b38
LayoutVideo (positioned) 0x32829f02c010 VIDEO 0x3a66b5286618 ID="video"
* LayoutBlockFlow (positioned) 0x32829f068010 DIV 0x3a66b528dd48 STYLE="font-size: 20px;"
LayoutFlexibleBox (relative positioned) 0x32829f03c010 DIV 0x3a66b5286d58
LayoutFlexibleBox (relative positioned) 0x32829f03c1d0 DIV 0x3a66b5286fd8
LayoutBlockFlow 0x32829f0185b0 DIV 0x3a66b52874c8
LayoutFlexibleBox (positioned) 0x32829f03c390 DIV 0x3a66b528c2a8 CLASS="loading-chip-wrapper"
LayoutBlockFlow 0x32829f0186d0 DIV 0x3a66b528c3b8 ID="loading-chip" CLASS="loading-chip-square"
LayoutImage 0x32829f024128 IMG 0x3a66b528c4c8
LayoutText 0x32829f044010 #text 0x3a66b528c5e8 "\n "
LayoutFlexibleBox (positioned) 0x32829f03c550 DIV 0x3a66b528c738 CLASS="loading-chip-wrapper"
LayoutFlexibleBox (positioned) 0x32829f03c710 DIV 0x3a66b528d0d8 CLASS="loading-chip-wrapper"
LayoutFlexibleBox (positioned) 0x32829f03c8d0 DIV 0x3a66b528da78 ID="toast-view" CLASS="toast-view"
A workaround is to remove the 'position: fixed' from
video::-webkit-media-text-track-container {
position: fixed;
top: 0;
left: 0;
right: 0;
bottom: 0;
max-height: 685px;
}
This bug doesn't affect dirty layout flags of the FrameView, so is not a case of 590856.
,
Aug 25 2016
Thanks for the analysis wangxianzhu. Lowering priority and marking as confirmed. Asserts in debug builds, while annoying, are not considered P1s. There are a number of lifecycles issues that we're working our way through but for the time being we are focusing on the ones that are causing crashes and security issues in release builds.
,
Aug 26 2016
Yep, thanks for the updates and fast analysis (and indeed, I didn't set this to P1, this is definitely non-urgent for us).
,
Aug 26 2016
I set it to P1 when I thought it were a case of bug 590856. Now P2 is more appropriate.
,
Aug 28 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 29 2017
,
Sep 22 2017
Can't repro now, I'm not sure if the bug was fixed or the HTML changed.
,
Oct 26 2017
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by wangxianzhu@chromium.org
, Aug 24 2016Cc: szager@chromium.org e...@chromium.org