fast/workers/worker-cloneport.html failing intermittently on leopard bot Marking as regression since it causes the tree to be red when it didn't used to be. ;) If that's not correct, please feel free to change. http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r48479%20(5083)/results.html --- layout-test-results/fast/workers/worker-cloneport-expected.txt 2009-09-17 11:49:57.000000000 -0700 +++ layout-test-results/fast/workers/worker-cloneport-actual.txt 2009-09-17 11:49:57.000000000 -0700 @@ -1,7 +1,7 @@ Test MessagePort messaging/entangle/detangle across threads. Should print "SUCCESS" when done. PASS: Received request for 50000 messages -PASS: postBack complete, cloned > 1000 times. +FAIL: postBack complete, but only cloned 635 times. SUCCESS - received 50000 messages. DONE
I'll reduce this restriction - it causes problems in Chromium as well because it makes assumptions about the speed/frequency of thread scheduling which don't really hold across all platforms.
Looks like dedicated-worker-lifecycle.html just failed too: http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r48488%20(5093)/results.html Not sure if that's related or not.
(In reply to comment #2) > Looks like dedicated-worker-lifecycle.html just failed too: > http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r48488%20(5093)/results.html > Not sure if that's related or not. Filed bug 29344 about that one.
Created attachment 39773 [details] proposed patch This test is intended to check for race conditions when cloning a port while posting messages to it from another thread. To ensure the case is adequately tested, we have some checks in place to make sure that clones are actually happening in parallel with messages being posted. The previous threshold (1000 clones) was chosen entirely arbitrarily, and turned out to be a order of magnitude too strict for some platforms (like Chromium). So I've loosened the requirement. I also relaxed a timeout that fires only in the test failure case, again because the latency involved in cross-process messaging in Chromium was causing it to be flaky.
Comment on attachment 39773 [details] proposed patch Adding 1 second to every run of this layout test is bad news bears. No other way besides setTimeout?
The timeout is only triggered when the test fails, to help in debugging why the test failed. It doesn't trigger when the test passes, so increasing the timeout does not slow down our tests. The patch includes a comment to this effect: // This only fires in the case of a test failure, so it does not slow down test running.
Comment on attachment 39773 [details] proposed patch Sounds good.
Thanks for taking care of this so quickly. :)
Comment on attachment 39773 [details] proposed patch Rejecting patch 39773 from commit-queue. Failed to run "['WebKitTools/Scripts/run-webkit-tests', '--no-launch-safari', '--quiet', '--exit-after-n-failures=1']" exit_code: 1 Running build-dumprendertree Running tests from /Users/eseidel/Projects/CommitQueue/LayoutTests Testing 11278 test cases. fast/workers/worker-cloneport.html -> failed Exiting early after 1 failures. 8198 tests run. 154.70s total testing time 8197 test cases (99%) succeeded 1 test case (<1%) had incorrect layout 3 test cases (<1%) had stderr output
Landed as r48543