54020 2011-02-08 10:45:05 -0800 fast/dom/null-document-location-href-put-crash.html is flaky 2011-02-10 17:22:39 -0800 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) PC Linux RESOLVED DUPLICATE 54157 P2 Normal --- 1 mario webkit-unassigned ggaren mrobinson oldest_to_newest 347503 0 mario 2011-02-08 10:45:05 -0800 This test is randomly failing every now and then in the GTK 32 bit release bot. As matter of fact I've observed today the following behavior: - Failed on builds #10506 and #10507 - Success on #10508 and #10509 - Fails on #10510 - Success on #10511 - Failed on #10512 and #10513 - Success on #10514 The diff output when failing is always the same: --- /var/lib/buildbot/build/gtk-linux-32-release/build/layout-test-results/fast/dom/null-document-location-href-put-crash-expected.txt 2011-02-08 08:51:34.000000000 -0800 +++ /var/lib/buildbot/build/gtk-linux-32-release/build/layout-test-results/fast/dom/null-document-location-href-put-crash-actual.txt 2011-02-08 08:51:34.000000000 -0800 @@ -1,4 +1,4 @@ +FAIL: Timed out waiting for notifyDone to be called This test checks for a NULL document crash that can happen when setting location.href. If the test passes, you'll see a PASS message below. -PASS: You didn't crash. Could it be that the usage of setTimeout(), combined with the fact of executing that JS code in the iframe, was leading to a race condition on here? [...] function main() { if (window.layoutTestController) { layoutTestController.dumpAsText(); layoutTestController.waitUntilDone(); } // setTimeout forces execution in the context of the frame frames[0].setTimeout(test, 0); } [...] Adding the author of the layout test in the meanwhile. Not skipping yet since at the moment is not failing (build 10514) 349527 1 mrobinson 2011-02-10 17:22:39 -0800 *** This bug has been marked as a duplicate of bug 54157 ***