"css3/filters/filter-repaint-composited-fallback.html" is flaky |
||||||||
Issue description"css3/filters/filter-repaint-composited-fallback.html" is flaky. This issue was created automatically by the chromium-try-flakes app. Please find the right owner to fix the respective test/step and assign this issue to them. If the step/test is infrastructure-related, please add Infra-Troopers label and change issue status to Untriaged. When done, please remove the issue from Sheriff Bug Queue by removing the Sheriff-Chromium label. We have detected 3 recent flakes. List of all flakes can be found at https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyPwsSBUZsYWtlIjRjc3MzL2ZpbHRlcnMvZmlsdGVyLXJlcGFpbnQtY29tcG9zaXRlZC1mYWxsYmFjay5odG1sDA. Flaky tests should be disabled within 30 minutes unless culprit CL is found and reverted. Please see more details here: https://sites.google.com/a/chromium.org/dev/developers/tree-sheriffs/sheriffing-bug-queues#triaging-auto-filed-flakiness-bugs
,
Jul 31
@pdr - can you help me find the right owner for this?
,
Jul 31
Dropping the sheriff label as this is being investigated and tests have been marked flaky.
,
Aug 4
Issue 867376 has been merged into this issue.
,
Aug 4
I think we're timing out because multiple tests are running DirectRenderer::DrawFrame for the first time simultaneously which causes tests to exceed 8s. On my high end Macbook pro: third_party/blink/tools/run_web_tests.py css3/filters/filter-repaint-composited-fallback.html --debug --no-retry-failures --details --iterations=1 -f test passes in 2.6s third_party/blink/tools/run_web_tests.py css3/filters/filter-repaint-composited-fallback.html --debug --no-retry-failures --details --iterations=2 -f each test takes ~3.1s ... third_party/blink/tools/run_web_tests.py css3/filters/filter-repaint-composited-fallback.html --debug --no-retry-failures --details --iterations=8 -f each test takes ~7s The test timeout is ~8s so I think it's likely that the bot is timing out due to running multiple tests with dumpAsTextWithPixelResults simultaneously. One strange thing is that the tests are only slow on the first run. For example: third_party/blink/tools/run_web_tests.py css3/filters/filter-repaint-composited-fallback.html --debug --no-retry-failures --details --iterations=100 -f The tests takes on average about ~0.3s I managed to get a trace and it looks like DirectRenderer::DrawFrame is what is expensive. When running a single test, on the first run, it takes ~2.1s. If a single test is run twice without the -f flag (so the second run of the test re-uses the first run's renderer), it finishes very fast. I think DirectRenderer::DrawFrame may have some pathological behavior when run for the first time. @reveman, can you investigate the cause of DirectRenderer::DrawFrame taking ~2s on first run? third_party/blink/tools/run_web_tests.py css3/filters/filter-repaint-composited-fallback.html --debug --no-retry-failures
,
Aug 4
,
Aug 7
Chris reports that this could be due to switching to software ANGLE for mac layout tests. CC'ing some folks who were involved in that.
,
Dec 17
,
Dec 18
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by fdegans@chromium.org
, Jul 31Status: Duplicate (was: Untriaged)