Bug 210849

compositing/overflow/rtl-scrollbar-layer-positioning.html This test is also flakily failing on iOS15 with the same error message.

HISTORY: https://results.webkit.org/?suite=layout-tests&test=compositing%2Foverflow%2Frtl-scrollbar-layer-positioning.html DIFF: --- /Volumes/Data/worker/Apple-iOS-15-Simulator-Debug-WK2-Tests/build/layout-test-results/compositing/overflow/rtl-scrollbar-layer-positioning-expected.txt +++ /Volumes/Data/worker/Apple-iOS-15-Simulator-Debug-WK2-Tests/build/layout-test-results/compositing/overflow/rtl-scrollbar-layer-positioning-actual.txt @@ -1,51 +1 @@ -(GraphicsLayer - (anchor 0.00 0.00) - (bounds 800.00 600.00) - (children 1 - (GraphicsLayer - (bounds 800.00 600.00) - (contentsOpaque 1) - (children 1 - (GraphicsLayer - (offsetFromRenderer width=-10 height=-10) - (position 18.00 10.00) - (bounds 362.00 362.00) - (drawsContent 1) - (children 2 - (GraphicsLayer - (offsetFromRenderer width=13 height=13) - (position 23.00 23.00) - (bounds origin 292.00 0.00) - (bounds 316.00 316.00) - (children 1 - (GraphicsLayer - (offsetFromRenderer width=13 height=13) - (scrollOffset (292,0)) - (anchor 0.00 0.00) - (bounds 608.00 616.00) - ) - ) - ) - (GraphicsLayer - (position 23.00 23.00) - (bounds 316.00 316.00) - (children 2 - (GraphicsLayer - (position 0.00 301.00) - (bounds 316.00 15.00) - (drawsContent 1) - ) - (GraphicsLayer - (position 301.00 0.00) - (bounds 15.00 316.00) - (drawsContent 1) - ) - ) - ) - ) - ) - ) - ) - ) -) - +<unknown> - TestController::run - Failed to reset state to consistent values DIFF URL: https://build.webkit.org/results/Apple-iOS-15-Simulator-Debug-WK2-Tests/250363@main%20(2489)/compositing/overflow/rtl-scrollbar-layer-positioning-pretty-diff.html

(In reply to Hercules Hjalmarsson from comment #1) > compositing/overflow/rtl-scrollbar-layer-positioning.html > > This test is also flakily failing on iOS15 with the same error message. The flaky failure on IOS15 shows up as a timeout in history.

<rdar://problem/97994145>

I wasn't able to reproduce the flaky timeout on iOS15 using command: run-webkit-tests --ios-simulator --iterations=10000 -f --clobber-old-results --child-processes=4 --debug compositing/overflow/rtl-scrollbar-layer-positioning.html

Test gardening commit 253050@main (017325709f18): <https://commits.webkit.org/253050@main> Reviewed commits have been landed. Closing PR #2960 and removing active labels.

Ignore the gtk results for now. On iOS, I don't think this test itself is timing out; the test has no waitUntilDone(). If I look at a full test run, like https://build.webkit.org/#/builders/529/builds/265/steps/12/logs/stdio, it shows: 22:58:11.505 22310 worker/0 compositing/overflow/resize-painting.html passed 22:58:46.633 22310 worker/0 "/usr/bin/sudo -n /usr/bin/tailspin save -n /var/folders/r2/b6clyg993dj_wywsgzrbstn00000gn/T/tmpj1lnhhqx/WebKitTestRunnerApp.app-22808-tailspin-temp.txt" took 0.13s 22:58:59.108 22310 worker/0 "/usr/bin/sample 22808 10 10 -file /var/folders/r2/b6clyg993dj_wywsgzrbstn00000gn/T/tmpj1lnhhqx/WebKitTestRunnerApp.app-22808-sample.txt" took 12.47s 22:58:59.133 22310 worker/0 "/usr/bin/sudo -n /usr/bin/tailspin save -n /var/folders/r2/b6clyg993dj_wywsgzrbstn00000gn/T/tmpk9wl7040/WebKitTestRunnerApp.app-22808-tailspin-temp.txt" took 0.02s 22:59:09.404 22310 worker/0 "/usr/bin/sample 22808 10 10 -file /var/folders/r2/b6clyg993dj_wywsgzrbstn00000gn/T/tmpk9wl7040/WebKitTestRunnerApp.app-22808-sample.txt" took 10.27s 22:59:09.411 22310 worker/0 "/usr/libexec/PlistBuddy -c Print CFBundleExecutable /Volumes/Data/worker/Apple-iOS-15-Simulator-Release-arm64-WK2-Tests/build/WebKitBuild/Release-iphonesimulator/WebKitTestRunnerApp.app/Info.plist" took 0.01s 22:59:09.440 22310 worker/0 killed pid 22808 22:59:09.443 22310 worker/0 killing driver 22:59:09.448 22310 worker/0 compositing/overflow/rtl-scrollbar-layer-positioning.html failed: 22:59:09.448 22310 worker/0 test timed out 22:59:09.448 22310 worker/0 no output from test 22:59:09.687 22310 worker/0 "xcrun simctl launch 972249EF-044D-41B1-A680-8F5AFD03B7C2 org.webkit.WebKitTestRunnerApp -" took 0.24s I find those spindumps anywhere.

I found the samples: https://build.webkit.org/results/Apple-iOS-15-Simulator-Release-arm64-WK2-Tests/252686@main%20(265)/ They show WTR getting stuck talking to the web process under various "reset to defaults" calls: + 837 -[WebKitTestRunnerApp _runTestController] (in WebKitTestRunnerApp) + 40 [0x1005efa44] + 837 WTR::TestController::TestController(int, char const**) (in WebKitTestRunnerApp) + 340 [0x1006012d4] + 837 WTR::TestController::runTestingServerLoop() (in WebKitTestRunnerApp) + 124 [0x1006063b0] + 837 WTR::TestController::runTest(char const*) (in WebKitTestRunnerApp) + 312 [0x100606110] + 837 WTR::TestInvocation::invoke() (in WebKitTestRunnerApp) + 384 [0x10061e928] + 837 WTR::TestController::resetStateToConsistentValues(WTR::TestOptions const&, WTR::TestController::ResetStage) (in WebKitTestRunnerApp) + 1296 [0x10060482c] + 837 WTR::TestController::statisticsResetToConsistentState() (in WebKitTestRunnerApp) + 76 [0x100604fd8] + 837 WTR::TestController::platformRunUntil(bool&, WTF::Seconds) (in WebKitTestRunnerApp) + 200 [0x1006169e0] + 837 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] (in Foundation) + 232 [0x102f3f5bc] + 837 CFRunLoopRunSpecific (in CoreFoundation) + 572 [0x10454a804] + 837 __CFRunLoopRun (in CoreFoundation) + 1096 [0x10454b164] + 837 __CFRunLoopServiceMachPort (in CoreFoundation) + 368 [0x104550d58] + 837 mach_msg (in libsystem_kernel.dylib) + 72 [0x104e95430] + 838 -[WebKitTestRunnerApp _runTestController] (in WebKitTestRunnerApp) + 40 [0x102597a44] + 838 WTR::TestController::TestController(int, char const**) (in WebKitTestRunnerApp) + 340 [0x1025a92d4] + 838 WTR::TestController::runTestingServerLoop() (in WebKitTestRunnerApp) + 124 [0x1025ae3b0] + 838 WTR::TestController::runTest(char const*) (in WebKitTestRunnerApp) + 312 [0x1025ae110] + 838 WTR::TestInvocation::invoke() (in WebKitTestRunnerApp) + 384 [0x1025c6928] + 838 WTR::TestController::resetStateToConsistentValues(WTR::TestOptions const&, WTR::TestController::ResetStage) (in WebKitTestRunnerApp) + 1296 [0x1025ac82c] + 838 WTR::TestController::statisticsResetToConsistentState() (in WebKitTestRunnerApp) + 76 [0x1025acfd8] + 838 WTR::TestController::platformRunUntil(bool&, WTF::Seconds) (in WebKitTestRunnerApp) + 200 [0x1025be9e0] + 838 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] (in Foundation) + 232 [0x104fc75bc] + 838 CFRunLoopRunSpecific (in CoreFoundation) + 572 [0x1065d2804] + 838 __CFRunLoopRun (in CoreFoundation) + 1096 [0x1065d3164] + 838 __CFRunLoopServiceMachPort (in CoreFoundation) + 368 [0x1065d8d58] + 838 mach_msg (in libsystem_kernel.dylib) + 72 [0x108fa9430] + 846 WTR::TestController::runTestingServerLoop() (in WebKitTestRunnerApp) + 124 [0x1007c63b0] + 846 WTR::TestController::runTest(char const*) (in WebKitTestRunnerApp) + 312 [0x1007c6110] + 846 WTR::TestInvocation::invoke() (in WebKitTestRunnerApp) + 32 [0x1007de7c8] + 846 WTR::TestController::configureViewForTest(WTR::TestInvocation const&) (in WebKitTestRunnerApp) + 28 [0x1007c5f90] + 846 WTR::TestController::ensureViewSupportsOptionsForTest(WTR::TestInvocation const&) (in WebKitTestRunnerApp) + 280 [0x1007c42b4] + 846 WTR::TestController::resetStateToConsistentValues(WTR::TestOptions const&, WTR::TestController::ResetStage) (in WebKitTestRunnerApp) + 1320 [0x1007c4844] + 846 WTR::TestController::clearPrivateClickMeasurement() (in WebKitTestRunnerApp) + 76 [0x1007c50a0] + 846 WTR::TestController::platformRunUntil(bool&, WTF::Seconds) (in WebKitTestRunnerApp) + 200 [0x1007d69e0] + 846 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] (in Foundation) + 232 [0x10320b5bc] + 846 CFRunLoopRunSpecific (in CoreFoundation) + 572 [0x104816804] + 846 __CFRunLoopRun (in CoreFoundation) + 1096 [0x104817164] + 846 __CFRunLoopServiceMachPort (in CoreFoundation) + 368 [0x10481cd58] + 846 mach_msg (in libsystem_kernel.dylib) + 72 [0x1071ed430] I suspect if we had a WebContent sample that we'd see some kind of IPC deadlock.

This

This flaky timeout is still occurring on iOS 17.

This test is passing for WebKitGTK since 275045@main ([GTK] Enable `forceCompositingMode` by default). https://results.webkit.org/?platform=GTK&platform=WPE&suite=layout-tests&test=compositing%2Foverflow%2Frtl-scrollbar-layer-positioning.html In the case of iOS, it doesn't seem like this test is very flaky anymore. https://results.webkit.org/?platform=ios&suite=layout-tests&test=compositing%2Foverflow%2Frtl-scrollbar-layer-positioning.html Since there's still a test referring this bug in LayoutTests/platform/ios/TestExpectations, I won't close this bug.