<rdar://problem/99707034>

This looks like a dupe of bug 166824.

I cannot reproduce at https://commits.webkit.org/255418@main On Linux GTK non-ASAN debug build, I'm hitting: ASSERTION FAILED: m_repaintRectsValid => m_repaintRects.outlineBoundsRect == renderer().outlineBoundsForRepaint(renderer().containerForRepaint().renderer) /app/webkit/Source/WebCore/rendering/RenderLayer.cpp(1234) : void WebCore::RenderLayer::recursiveUpdateLayerPositionsAfterScroll(WebCore::RenderGeometryMap*, WTF::OptionSet<UpdateLayerPositionsAfterScrollFlag>) On macOS ASAN debug build, I'm hitting: ASSERTION FAILED: rareData->m_enclosingFragmentedFlow.value() == RenderBox::locateEnclosingFragmentedFlow() rendering/RenderBlock.cpp(2721) : virtual WebCore::RenderFragmentedFlow *WebCore::RenderBlock::locateEnclosingFragmentedFlow() const No crashes in release builds.

Another assertion that it hit on ASAN macOS debug build: ASSERTION FAILED: willBeComposited == needsToBeComposited(layer, queryData) rendering/RenderLayerCompositor.cpp(1189) : void WebCore::RenderLayerCompositor::computeCompositingRequirements(WebCore::RenderLayer *, WebCore::RenderLayer &, WebCore::LayerOverlapMap &, WebCore::RenderLayerCompositor::CompositingState &, WebCore::RenderLayerCompositor::BackingSharingState &, bool &)

Created attachment 463055 [details] Python script to extract data: URLs When trying to reduce the testcase I'm also seeing bug 244465 on macOS. For now I haven't been very successful reducing the tests. Some observation: - The end of the file contains many rdfuzz-script doing JS mutations via setTimeout of increasing duration. This is making the test very slow. It's possible to speed up things a bit by dividing that duration by a constant. - Several images are inserted as data URL, which makes the HTML large. The attached Python script helps to extract these data URL as external resources.

Created attachment 463077 [details] Slightly reduced Based on comment 5: - I tweaked my Python script to convert data URLs of images into data URLs of blank SVG images of same size. This makes the size goes down from 6.24MB to 2.8MB. - I also added a scalar parameter α for the setTimeout functions, which one can tweak to reduce the runtime. For example on Linux GTK non-ASAN debug build the time to hit an assertion goes down from ~40s to ~20s with α=0.1. These change don't seem to affect the reproducibility of debug assertions (although I'm still not able to reproduce the original one from the report). This is still not optimal, but hopefully this will help further testcase reduction. Incidentally, I just hit another one in macOS ASAN debug build: ASSERTION FAILED: LayoutPoint(IntPoint(paintOffset.x(), paintOffset.y())) == paintOffset rendering/RenderView.cpp(327) : virtual void WebCore::RenderView::paint(WebCore::PaintInfo &, const WebCore::LayoutPoint &) and with Linux GTK non-ASAN debug build, I also hit the one from comment 4.

(In reply to Frédéric Wang (:fredw) from comment #5) > Created attachment 463055 [details] > Python script to extract data: URLs > > When trying to reduce the testcase I'm also seeing bug 244465 on macOS. > > For now I haven't been very successful reducing the tests. Some observation: > > - The end of the file contains many rdfuzz-script doing JS mutations via > setTimeout of increasing duration. This is making the test very slow. It's > possible to speed up things a bit by dividing that duration by a constant. > > - Several images are inserted as data URL, which makes the HTML large. The > attached Python script helps to extract these data URL as external resources. I did more attempt today. I noticed that assertions are sometimes flaky with the original test and the more you reduce the file's size, the more flaky it becomes. My guess is that it is due to the setTimeout calls at the end of the file (performing DOM mutations) which are not guaranteed to execute. Adding testRunner.waitUntilDone/notifyDone() before/after helps the reduction. I've attached a few more reduced testcases for different assertions. Will try to do more tomorrow for other assertions I found from the original testcase.

Comment on attachment 463123 [details] ASSERTION FAILED: rareData->m_enclosingFragmentedFlow.value() == RenderBox::locateEnclosingFragmentedFlow() Testing again at https://commits.webkit.org/255905@main : - "ASSERTION FAILED: rareData->m_enclosingFragmentedFlow.value() == RenderBox::locateEnclosingFragmentedFlow()" is now fixed, so I'm marking attachment 463123 [details] as obsolete. - I've been able to reproduce the original assertion "ASSERTION FAILED: isPlaced()" and to reduce it to a test case of ~750kb, but the more I'm reducing it, the more it becomes flaky. I'll try to improve that and upload a test case later.

Created attachment 463221 [details] Minimized testcase Attached is a minimized testcase for ASSERTION FAILED: isPlaced(). Reproduced at https://commits.webkit.org/255905@main with macos/GTK debug builds.

The backtrace with the minimized testcase seems slightly different than the one of the original report: ASSERTION FAILED: isPlaced() rendering/FloatingObjects.h(60) : WebCore::LayoutUnit WebCore::FloatingObject::maxY() const 1 0x1372ee330 WTFCrash 2 0x2806ecb00 WebCore::JSBeforeUnloadEvent::createPrototype(JSC::VM&, WebCore::JSDOMGlobalObject&) 3 0x2853913d8 WebCore::FloatingObject::maxY() const 4 0x285390ff0 WebCore::RenderBlockFlow::logicalBottomForFloat(WebCore::FloatingObject const&) const 5 0x285473360 WebCore::RenderBlockFlow::addOverhangingFloats(WebCore::RenderBlockFlow&, bool) 6 0x2854748f0 WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox&, WebCore::RenderBlockFlow::MarginInfo&, WebCore::LayoutUnit&, WebCore::LayoutUnit&) 7 0x285472f0c WebCore::RenderBlockFlow::layoutBlockChildren(bool, WebCore::LayoutUnit&) 8 0x285472064 WebCore::RenderBlockFlow::layoutBlock(bool, WebCore::LayoutUnit) 9 0x2854571d8 WebCore::RenderBlock::layout() 10 0x2854745c0 WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox&, WebCore::RenderBlockFlow::MarginInfo&, WebCore::LayoutUnit&, WebCore::LayoutUnit&) 11 0x285472f0c WebCore::RenderBlockFlow::layoutBlockChildren(bool, WebCore::LayoutUnit&) 12 0x285472064 WebCore::RenderBlockFlow::layoutBlock(bool, WebCore::LayoutUnit) 13 0x2854571d8 WebCore::RenderBlock::layout() 14 0x2854745c0 WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox&, WebCore::RenderBlockFlow::MarginInfo&, WebCore::LayoutUnit&, WebCore::LayoutUnit&) 15 0x285472f0c WebCore::RenderBlockFlow::layoutBlockChildren(bool, WebCore::LayoutUnit&) 16 0x285472064 WebCore::RenderBlockFlow::layoutBlock(bool, WebCore::LayoutUnit) 17 0x2854571d8 WebCore::RenderBlock::layout() 18 0x2854745c0 WebCore::RenderBlockFlow::layoutBlockChild(WebCore::RenderBox&, WebCore::RenderBlockFlow::MarginInfo&, WebCore::LayoutUnit&, WebCore::LayoutUnit&) 19 0x285472f0c WebCore::RenderBlockFlow::layoutBlockChildren(bool, WebCore::LayoutUnit&) 20 0x285472064 WebCore::RenderBlockFlow::layoutBlock(bool, WebCore::LayoutUnit) 21 0x2854571d8 WebCore::RenderBlock::layout() 22 0x285707ae0 WebCore::RenderView::layout() 23 0x2848c8744 WebCore::FrameViewLayoutContext::performLayout() 24 0x2848c8064 WebCore::FrameViewLayoutContext::layout() 25 0x28386125c WebCore::Document::implicitClose() 26 0x2845ef508 WebCore::FrameLoader::checkCallImplicitClose() 27 0x2845eeeac WebCore::FrameLoader::checkCompleted() 28 0x2845ed318 WebCore::FrameLoader::finishedParsing() 29 0x283875c18 WebCore::Document::finishedParsing() 30 0x2840b1934 WebCore::HTMLConstructionSite::finishedParsing() 31 0x2840febc8 WebCore::HTMLTreeBuilder::finished() com.apple.WebKit.WebContent.Development terminated (pid 64292) for reason: crash #CRASHED - com.apple.WebKit.WebContent.Development (pid 64292) LEAK: 1 WebProcessPool LEAK: 1 WebPageProxy

*** Bug 166824 has been marked as a duplicate of this bug. ***

Let's try reproducing with Release builds, both non-ASAN and ASAN.

(In reply to Michael Saboff from comment #21) > Let's try reproducing with Release builds, both non-ASAN and ASAN. The 6MB test does not crash with non-ASAN and ASAN Release builds.

I've checked asan and not asan builds, as well as Debug builds in Mac and GTK. The only crashes I found were both in Debug builds, in Mac and GTK. There are no crashes with the original large test in Release builds, asan or not. Here is the trace for Debug GTK: #0 WTFCrash() () at /app/webkit/Source/WTF/wtf/Assertions.cpp:327 #1 0x00007ff15e2b7636 in WebCore::RenderLayer::recursiveUpdateLayerPositionsAfterScroll(WebCore::RenderGeometryMap*, WTF::OptionSet<WebCore::RenderLayer::UpdateLayerPositionsAfterScrollFlag>) (this=0x7ff0b6048b50, geometryMap=0x7ffc449b40b0, flags=...) at /app/webkit/Source/WebCore/rendering/RenderLayer.cpp:1245 #2 0x00007ff15e2b7661 in WebCore::RenderLayer::recursiveUpdateLayerPositionsAfterScroll(WebCore::RenderGeometryMap*, WTF::OptionSet<WebCore::RenderLayer::UpdateLayerPositionsAfterScrollFlag>) (this=0x7ff0b6038660, geometryMap=0x7ffc449b40b0, flags=...) at /app/webkit/Source/WebCore/rendering/RenderLayer.cpp:1249 #3 0x00007ff15e2b7661 in WebCore::RenderLayer::recursiveUpdateLayerPositionsAfterScroll(WebCore::RenderGeometryMap*, WTF::OptionSet<WebCore::RenderLayer::UpdateLayerPositionsAfterScrollFlag>) (this=0x7ff0b6002c70, geometryMap=0x7ffc449b40b0, flags=...) at /app/webkit/Source/WebCore/rendering/RenderLayer.cpp:1249 #4 0x00007ff15e2b7661 in WebCore::RenderLayer::recursiveUpdateLayerPositionsAfterScroll(WebCore::RenderGeometryMap*, WTF::OptionSet<WebCore::RenderLayer::UpdateLayerPositionsAfterScrollFlag>) (this=0x7ff0b6000c80, geometryMap=0x7ffc449b40b0, flags=...) at /app/webkit/Source/WebCore/rendering/RenderLayer.cpp:1249 #5 0x00007ff15e2b7193 in WebCore::RenderLayer::updateLayerPositionsAfterDocumentScroll() (this=0x7ff0b6000c80) at /app/webkit/Source/WebCore/rendering/RenderLayer.cpp:1200 #6 0x00007ff15d90e31f in WebCore::LocalFrameView::updateLayerPositionsAfterScrolling() (this=0x7ff0b60000b0) at /app/webkit/Source/WebCore/page/LocalFrameView.cpp:2982 #7 0x00007ff15db819a5 in WebCore::ScrollView::completeUpdatesAfterScrollTo(WebCore::IntSize const&) (this=0x7ff0b60000b0, scrollDelta=...) at /app/webkit/Source/WebCore/platform/ScrollView.cpp:524 #8 0x00007ff15db815b5 in WebCore::ScrollView::handleDeferredScrollUpdateAfterContentSizeChange() (this=0x7ff0b60000b0) at /app/webkit/Source/WebCore/platform/ScrollView.cpp:479 #9 0x00007ff15d9059ae in WebCore::LocalFrameView::didLayout(WTF::WeakPtr<WebCore::RenderElement, WTF::DefaultWeakPtrImpl>) (this=0x7ff0b60000b0, layoutRoot=...) at /app/webkit/Source/WebCore/page/LocalFrameView.cpp:1371 #10 0x00007ff15d91e24e in WebCore::LocalFrameViewLayoutContext::performLayout() (this=0x7ff0b6000210) at /app/webkit/Source/WebCore/page/LocalFrameViewLayoutContext.cpp:281 #11 0x00007ff15d91d6e7 in WebCore::LocalFrameViewLayoutContext::layout() (this=0x7ff0b6000210) at /app/webkit/Source/WebCore/page/LocalFrameViewLayoutContext.cpp:173 #12 0x00007ff15d91f2d3 in WebCore::LocalFrameViewLayoutContext::layoutTimerFired() (this=0x7ff0b6000210) at /app/webkit/Source/WebCore/page/LocalFrameViewLayoutContext.cpp:483 #13 0x00007ff15d956694 in std::__invoke_impl<void, void (WebCore::LocalFrameViewLayoutContext::*&)(), WebCore::LocalFrameViewLayoutContext*&>(std::__invoke_memfun_deref, void (WebCore::LocalFrameViewLayoutContext::*&)(), WebCore::LocalFrameViewLayoutContext*&) (__f=@0x7ff139204388: (void (WebCore::LocalFrameViewLayoutContext::*)(WebCore::LocalFrameViewLayoutContext * const)) 0x7ff15d91f130 <WebCore::LocalFrameViewLayoutContext::layoutTimerFired()>, __t=@0x7ff139204398: 0x7ff0b6000210) at /usr/include/c++/12.2.0/bits/invoke.h:74 #14 0x00007ff15d956585 in std::__invoke<void (WebCore::LocalFrameViewLayoutContext::*&)(), WebCore::LocalFrameViewLayoutContext*&>(void (WebCore::LocalFrameViewLayoutContext::*&)(), WebCore::LocalFrameViewLayoutContext*&) (__fn=@0x7ff139204388: (void (WebCore::LocalFrameViewLayoutContext::*)(WebCore::LocalFrameViewLayoutContext * const)) 0x7ff15d91f130 <WebCore::LocalFrameViewLayoutContext::layoutTimerFired()>) at /usr/include/c++/12.2.0/bits/invoke.h:96 #15 0x00007ff15d95648d in std::_Bind<void (WebCore::LocalFrameViewLayoutContext::*(WebCore::LocalFrameViewLayoutContext*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (this=0x7ff139204388, __args=...) at /usr/include/c++/12.2.0/functional:484 #16 0x00007ff15d9563d5 in std::_Bind<void (WebCore::LocalFrameViewLayoutContext::*(WebCore::LocalFrameViewLayoutContext*))()>::operator()<, void>() (this=0x7ff139204388) at /usr/include/c++/12.2.0/functional:567 #17 0x00007ff15d95637e in WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::LocalFrameViewLayoutContext::*(WebCore::LocalFrameViewLayoutContext*))()>, void>::call() (this=0x7ff139204380) at /app/webkit/WebKitBuild/Debug/WTF/Headers/wtf/Function.h:53 #18 0x00007ff1588bbfa9 in WTF::Function<void ()>::operator()() const (this=0x7ff0b6000240) at /app/webkit/WebKitBuild/Debug/WTF/Headers/wtf/Function.h:82 #19 0x00007ff1589c0992 in WebCore::Timer::fired() (this=0x7ff0b6000218) at /app/webkit/WebKitBuild/Debug/WebCore/PrivateHeaders/WebCore/Timer.h:135 #20 0x00007ff15dbb92b2 in WebCore::ThreadTimers::sharedTimerFiredInternal() (this=0x7ff1390f3a50) at /app/webkit/Source/WebCore/platform/ThreadTimers.cpp:127 #21 0x00007ff15dbb8ba3 in operator()() const (__closure=0x7ff139000228) at /app/webkit/Source/WebCore/platform/ThreadTimers.cpp:67 #22 0x00007ff15dbbc068 in WTF::Detail::CallableWrapper<WebCore::ThreadTimers::setSharedTimer(WebCore::SharedTimer*)::<lambda()>, void>::call(void) (this=0x7ff139000220) at /app/webkit/WebKitBuild/Debug/WTF/Headers/wtf/Function.h:53 #23 0x00007ff1588bbfa9 in WTF::Function<void ()>::operator()() const (this=0x7ff15f95b1c8 <WebCore::MainThreadSharedTimer::singleton()::instance+8>) at /app/webkit/WebKitBuild/Debug/WTF/Headers/wtf/Function.h:82 #24 0x00007ff15db60dd4 in WebCore::MainThreadSharedTimer::fired() (this=0x7ff15f95b1c0 <WebCore::MainThreadSharedTimer::singleton()::instance>) at /app/webkit/Source/WebCore/platform/MainThreadSharedTimer.cpp:83 #25 0x00007ff15db66d84 in std::__invoke_impl<void, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(std::__invoke_memfun_deref, void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (__f=@0x7ff1390f5648: (void (WebCore::MainThreadSharedTimer::*)(WebCore::MainThreadSharedTimer * const)) 0x7ff15db60d4c <WebCore::MainThreadSharedTimer::fired()>, __t=@0x7ff1390f5658: 0x7ff15f95b1c0 <WebCore--Type <RET> for more, q to quit, c to continue without paging-- ::MainThreadSharedTimer::singleton()::instance>) at /usr/include/c++/12.2.0/bits/invoke.h:74 #26 0x00007ff15db66cfd in std::__invoke<void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&>(void (WebCore::MainThreadSharedTimer::*&)(), WebCore::MainThreadSharedTimer*&) (__fn=@0x7ff1390f5648: (void (WebCore::MainThreadSharedTimer::*)(WebCore::MainThreadSharedTimer * const)) 0x7ff15db60d4c <WebCore::MainThreadSharedTimer::fired()>) at /usr/include/c++/12.2.0/bits/invoke.h:96 #27 0x00007ff15db66c73 in std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::__call<void, , 0ul>(std::tuple<>&&, std::_Index_tuple<0ul>) (this=0x7ff1390f5648, __args=...) at /usr/include/c++/12.2.0/functional:484 #28 0x00007ff15db66c05 in std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>::operator()<, void>() (this=0x7ff1390f5648) at /usr/include/c++/12.2.0/functional:567 #29 0x00007ff15db66bce in WTF::Detail::CallableWrapper<std::_Bind<void (WebCore::MainThreadSharedTimer::*(WebCore::MainThreadSharedTimer*))()>, void>::call() (this=0x7ff1390f5640) at /app/webkit/WebKitBuild/Debug/WTF/Headers/wtf/Function.h:53 #30 0x00007ff1588bbfa9 in WTF::Function<void ()>::operator()() const (this=0x7ff15f95b1f8 <WebCore::MainThreadSharedTimer::singleton()::instance+56>) at /app/webkit/WebKitBuild/Debug/WTF/Headers/wtf/Function.h:82 #31 0x00007ff1589c0aa2 in WTF::RunLoop::Timer::fired() (this=0x7ff15f95b1d0 <WebCore::MainThreadSharedTimer::singleton()::instance+16>) at /app/webkit/WebKitBuild/Debug/WTF/Headers/wtf/RunLoop.h:195 #32 0x00007ff14e1e627d in operator()(gpointer) const (__closure=0x0, userData=0x7ff15f95b1d0 <WebCore::MainThreadSharedTimer::singleton()::instance+16>) at /app/webkit/Source/WTF/wtf/glib/RunLoopGLib.cpp:177 #33 0x00007ff14e1e62bd in _FUN(gpointer) () at /app/webkit/Source/WTF/wtf/glib/RunLoopGLib.cpp:181 #34 0x00007ff14e1e57cf in operator()(GSource*, GSourceFunc, gpointer) const (__closure=0x0, source=0x555fa16facf0, callback=0x7ff14e1e62a0 <_FUN(gpointer)>, userData=0x7ff15f95b1d0 <WebCore::MainThreadSharedTimer::singleton()::instance+16>) at /app/webkit/Source/WTF/wtf/glib/RunLoopGLib.cpp:53 #35 0x00007ff14e1e581d in _FUN(GSource*, GSourceFunc, gpointer) () at /app/webkit/Source/WTF/wtf/glib/RunLoopGLib.cpp:56 #36 0x00007ff147520c37 in g_main_dispatch (context=0x555fa12132d0) at ../glib/gmain.c:3419 #37 g_main_context_dispatch (context=0x555fa12132d0) at ../glib/gmain.c:4137 #38 0x00007ff147577028 in g_main_context_iterate.constprop.0 (context=0x555fa12132d0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4213 #39 0x00007ff1475202af in g_main_loop_run (loop=0x555fa1351c70) at ../glib/gmain.c:4413 #40 0x00007ff14e1e5e88 in WTF::RunLoop::run() () at /app/webkit/Source/WTF/wtf/glib/RunLoopGLib.cpp:108 #41 0x00007ff159a45863 in WebKit::AuxiliaryProcessMainBase<WebKit::WebProcess, true>::run(int, char**) (this=0x7ffc449b4d40, argc=4, argv=0x7ffc449b4f08) at /app/webkit/Source/WebKit/Shared/AuxiliaryProcessMain.h:72 #42 0x00007ff159a45692 in WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainGtk>(int, char**) (argc=4, argv=0x7ffc449b4f08) at /app/webkit/Source/WebKit/Shared/AuxiliaryProcessMain.h:98 #43 0x00007ff159a454c4 in WebKit::WebProcessMain(int, char**) (argc=4, argv=0x7ffc449b4f08) at /app/webkit/Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp:98 #44 0x0000555fa0824979 in main(int, char**) (argc=4, argv=0x7ffc449b4f08) at /app/webkit/Source/WebKit/WebProcess/EntryPoint/unix/WebProcessMain.cpp:31 (gdb) f 0 #0 WTFCrash () at /app/webkit/Source/WTF/wtf/Assertions.cpp:327

I was also unable to reproduce on any Release builds. We'll close this as it doesn't seem to be a security issue and is likely an over-eager debug assert.