Bug 29341 – REGRESSION: fast/workers/worker-cloneport.html failing intermittently on leopard bot

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

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

[Andrew Wilson]

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.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

(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.

[Andrew Wilson]

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.

[Eric Seidel (no email)]

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?

[Andrew Wilson]

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.

[Eric Seidel (no email)]

Comment on attachment 39773 [details]
proposed patch

Sounds good.

[Eric Seidel (no email)]

Thanks for taking care of this so quickly. :)

[WebKit Commit Bot]

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

[Andrew Wilson]

Landed as r48543