GTK/WPE layout-tests steps are timing out after r266221. Some tests seem to hold the driver alive, and the step fails with those "no console output for 1200 seconds". For example, running webaudio/ tests (defaults to 5 shards), webaudio/audiobuffersource-loop-points.html (skipped in mac in bug119467) get stuck and the test run does not progress. The same happens regardless of the number of shards, always getting stuck in this test. List of webaudio/ tests skipped to allow all other webaudio/ tests to run: * webaudio/audiobuffersource-loop-points.html * webaudio/audiobuffersource-playbackrate.html PS: Not sure if this happens due to some webkitpy bug uncovered by these timeouts.
Interesting. I had some very slow layout tests runs locally as well until I rebaselined the couple of Web Audio tests that were failing. You should consider rebaselining the couple of tests that are failing with audio diff to see if it makes the issue go away (Seems like it did on macOS).
(In reply to Chris Dumez from comment #1) > Interesting. I had some very slow layout tests runs locally as well until I > rebaselined the couple of Web Audio tests that were failing. > > You should consider rebaselining the couple of tests that are failing with > audio diff to see if it makes the issue go away (Seems like it did on macOS). Indeed rebaselining made the test pass. O_o In any case, the test suite should not hang because a WAV diff failed, no?
(In reply to Lauro Moura from comment #2) > (In reply to Chris Dumez from comment #1) > > Interesting. I had some very slow layout tests runs locally as well until I > > rebaselined the couple of Web Audio tests that were failing. > > > > You should consider rebaselining the couple of tests that are failing with > > audio diff to see if it makes the issue go away (Seems like it did on macOS). > > Indeed rebaselining made the test pass. O_o > > In any case, the test suite should not hang because a WAV diff failed, no? Yes, I suspect we have a tooling bug. I saw a Python process using 100% CPU constantly. I was just trying to help you get back in a good state.
(In reply to Chris Dumez from comment #3) > > I was just trying to help you get back in a good state. Sure, sure. Thanks. In the loop-points test, the new test results had small deviations that increased as the frequency increased (looping was right, though). This caused the WaveDiff class to generate a sample diff for 340k of the 666k samples. And as the current WaveDiff uses string concat for each sample diff, it ended up being too slow, likely leading the timeout to be triggered on the test controller and it somehow losing track of the runner.
Created attachment 407429 [details] Patch
Committed r266272: <https://trac.webkit.org/changeset/266272> All reviewed patches have been landed. Closing bug and clearing flags on attachment 407429 [details].
<rdar://problem/67915158>