NEW 112939
Flaky Test: fast/performance/performance-now-timestamps.html
https://bugs.webkit.org/show_bug.cgi?id=112939
Summary Flaky Test: fast/performance/performance-now-timestamps.html
WebKit Review Bot
Reported 2013-03-21 11:26:26 PDT
This is an automatically generated bug from the commit-queue. fast/performance/performance-now-timestamps.html has been flaky on the commit-queue. fast/performance/performance-now-timestamps.html was authored by nduca@chromium.org. http://trac.webkit.org/browser/trunk/LayoutTests/fast/performance/performance-now-timestamps.html The commit-queue just saw fast/performance/performance-now-timestamps.html flake (text diff) while processing attachment 194291 [details] on bug 112623. Bot: gce-cq-02 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-3.3.8-gcg-201212281604-x86_64-with-GCEL-10.04-gcel_10.04 The bots will update this with information from each new failure. If you believe this bug to be fixed or invalid, feel free to close. The bots will re-open if the flake re-occurs. If you would like to track this test fix with another bug, please close this bug as a duplicate. The bots will follow the duplicate chain when making future comments.
Attachments
Archive of layout-test-results from gce-cq-02 (969.43 KB, application/zip)
2013-03-21 11:26 PDT, WebKit Review Bot
no flags
Update Test Expectations (1.59 KB, patch)
2020-02-06 14:03 PST, Jacob Uphoff
no flags
WebKit Review Bot
Comment 1 2013-03-21 11:26:30 PDT
Created attachment 194300 [details] Archive of layout-test-results from gce-cq-02
Jacob Uphoff
Comment 3 2020-02-06 14:01:04 PST
Still being seen. History: https://results.webkit.org/?suite=layout-tests&test=fast%2Fperformance%2Fperformance-now-timestamps.html&limit=50000 Diff: --- /Volumes/Data/slave/catalina-debug-tests-wk1/build/layout-test-results/fast/performance/performance-now-timestamps-expected.txt +++ /Volumes/Data/slave/catalina-debug-tests-wk1/build/layout-test-results/fast/performance/performance-now-timestamps-actual.txt @@ -9,7 +9,7 @@ PASS secondTimestamp is defined. PASS secondTimestamp is >= firstTimestamp + (waitTime / 2) PASS elapsed is >= 1 -PASS elapsed < 100 is true +FAIL elapsed < 100 should be true. Was false. PASS successfullyParsed is true TEST COMPLETE
Jacob Uphoff
Comment 4 2020-02-06 14:01:21 PST
I can reproduce with just running the test in iterations.
Jacob Uphoff
Comment 5 2020-02-06 14:03:25 PST
Created attachment 389992 [details] Update Test Expectations
Radar WebKit Bug Importer
Comment 6 2020-02-06 14:05:04 PST
Truitt Savell
Comment 7 2020-02-06 14:10:12 PST
Comment on attachment 389992 [details] Update Test Expectations Clearing flags on attachment: 389992 Committed r255978: <https://trac.webkit.org/changeset/255978>
Mark Lam
Comment 8 2020-03-31 14:34:35 PDT
The test is merely measuring time around a busy wait with window.performance.now(), which is monotonic time. If the system is busy (as in running a gazillion other layout tests concurrently), the test process can be pre-empted with no guarantee that it will resume executing in time to read the end sample time within any duration that the test expects. In this case, the test is expecting a duration of 100ms. This test is just a bad test.
Note You need to log in before you can comment on or make changes to this bug.