fast/loader/cancel-load-during-port-block-timer.html fails on Tiger bot

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

fast/loader/cancel-load-during-port-block-timer.html fails on Tiger bot

http://build.webkit.org/results/Tiger%20Intel%20Release/r56294%20(9852)/fast/loader/cancel-load-during-port-block-timer-diffs.txt

--- /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/layout-test-results/fast/loader/cancel-load-during-port-block-timer-expected.txt	2010-03-19 20:43:53.000000000 -0700
+++ /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/layout-test-results/fast/loader/cancel-load-during-port-block-timer-actual.txt	2010-03-19 20:43:53.000000000 -0700
@@ -1 +1,8 @@
-If this does crash, the test has passed.
+layer at (0,0) size 1968x585
+  RenderView at (0,0) size 800x585
+layer at (0,0) size 1968x585
+  RenderBlock {HTML} at (0,0) size 800x585
+    RenderBody {BODY} at (8,8) size 784x564
+      RenderBlock {PRE} at (0,0) size 784x15
+        RenderText {#text} at (0,0) size 1960x15
+          text run at (0,0) width 1960: "This is an API test that will only work under DumpRenderTree. It tests using the WebKit api [WebView goToBackForwardItem:] to go to the current item. This needs to actually perform a \"real\" load, and not be treated as a same-document navigation."

http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/cancel-load-during-port-block-timer.html

[Eric Seidel (no email)]

This seems to have started after http://trac.webkit.org/changeset/56294, but I find it difficult to believe that that checkin was related.

[Eric Seidel (no email)]

Failed on the Leopard Commit bot as well just now:
https://bugs.webkit.org/show_bug.cgi?id=34350#c25

Looks like the test is flaky. :(

[Brady Eidson]

(In reply to comment #0)
> fast/loader/cancel-load-during-port-block-timer.html fails on Tiger bot
> 
> http://build.webkit.org/results/Tiger%20Intel%20Release/r56294%20(9852)/fast/loader/cancel-load-during-port-block-timer-diffs.txt
> 
> ---
> /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/layout-test-results/fast/loader/cancel-load-during-port-block-timer-expected.txt
>    2010-03-19 20:43:53.000000000 -0700
> +++
> /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/layout-test-results/fast/loader/cancel-load-during-port-block-timer-actual.txt
>    2010-03-19 20:43:53.000000000 -0700
> @@ -1 +1,8 @@
> -If this does crash, the test has passed.
> +layer at (0,0) size 1968x585
> +  RenderView at (0,0) size 800x585
> +layer at (0,0) size 1968x585
> +  RenderBlock {HTML} at (0,0) size 800x585
> +    RenderBody {BODY} at (8,8) size 784x564
> +      RenderBlock {PRE} at (0,0) size 784x15
> +        RenderText {#text} at (0,0) size 1960x15
> +          text run at (0,0) width 1960: "This is an API test that will only
> work under DumpRenderTree. It tests using the WebKit api [WebView
> goToBackForwardItem:] to go to the current item. This needs to actually perform
> a \"real\" load, and not be treated as a same-document navigation."
> 
> http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/cancel-load-during-port-block-timer.html

That failure is quite clearly from a different test - fast/loader/api-test-go-to-current-back-forward-item.html

[Brady Eidson]

(In reply to comment #2)
> Failed on the Leopard Commit bot as well just now:
> https://bugs.webkit.org/show_bug.cgi?id=34350#c25
> 
> Looks like the test is flaky. :(

Since the commit bot doesn't give the flaky output, I can't verify that that failure was also actually output from the previous test.

[Eric Seidel (no email)]

I'll upload the commit-bot's output shortly.

[Eric Seidel (no email)]

Created attachment 51328 [details]
pretty diff from failure on commit bot

Here is the failure from the commit bot.

[Eric Seidel (no email)]

Failed again
http://build.webkit.org/results/Tiger%20Intel%20Release/r56358%20(9902)/fast/loader/cancel-load-during-port-block-timer-diffs.txt

[Brady Eidson]

Definitely the API test before it failing.

Please disable the API test.  I don't have a checkout right now so I can't do it.

[Eric Seidel (no email)]

Created attachment 51359 [details]
Patch for landing

[Eric Seidel (no email)]

Created attachment 51360 [details]
Patch for landing

[Eric Seidel (no email)]

Thanks for the diagnosis Brady.

[Brady Eidson]

(In reply to comment #11)
> Thanks for the diagnosis Brady.

Sorry for the trouble with the test.  We need to find out why the previous test is leaking through to the next test's results.  I know this has come up a few times in the past, and I was DEFINITELY not the one who cracked the code.

We need a DRT/run-webkit-tests guru.

[WebKit Commit Bot]

Comment on attachment 51360 [details]
Patch for landing

Clearing flags on attachment: 51360

Committed r56378: <http://trac.webkit.org/changeset/56378>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.