The original test was broken into five parts by the previous chromium gardener, but each part is now timing out. Are these tests really this slow, or is this a bug?
These tests was splitted in r87726. Are there still problems after the split? Marcus should know about this.
Yes. All five splits are still timing out.
marked as TIMEOUT in r118829
Chromium has a shorter timeout than other WebKit ports (6 seconds on release and 12 on debug). We could mark these tests SLOW in the test_expectations.txt file and that would give them 30/60 seconds respectively. Testing locally, they complete at that point, but fail with a text diff. Looking at http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=svg%2Fdom%2Fviewspec-parser- these tests are slow on all ports. Taking up to 19 seconds on GTK debug and 30 seconds on Lion Release with a high variance. Is there any way we can make these tests faster? More importantly, why are we running fuzzer tests as part of the layout test suite? I realize that the randomization is deterministic, but this still doesn't seem appropriate in principle for layout testing. We run a fuzzer to find problems and then create dedicated reduced test-cases for those.
These tests also timeout a lot on Mac: http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK1%20(Tests)/r129157%20(1260)/results.html
FYI, webkit-dev discussion about this: http://lists.webkit.org/pipermail/webkit-dev/2012-June/021110.html.
I missed this bug report, please see bug 103744 for my patch.
*** This bug has been marked as a duplicate of bug 103744 ***