RESOLVED FIXED 36425
fast/loader/cancel-load-during-port-block-timer.html fails on Tiger bot 
https://bugs.webkit.org/show_bug.cgi?id=36425
Summary fast/loader/cancel-load-during-port-block-timer.html fails on Tiger bot
Eric Seidel (no email)
Reported 2010-03-21 05:14:56 PDT
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
Attachments
pretty diff from failure on commit bot (3.13 KB, text/html)
2010-03-22 12:24 PDT, Eric Seidel (no email) 		no flags
Details
Patch for landing (2.95 KB, patch)
2010-03-22 14:53 PDT, Eric Seidel (no email) 		no flags
DetailsFormatted DiffDiff
Patch for landing (3.12 KB, patch)
2010-03-22 14:54 PDT, Eric Seidel (no email) 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2010-03-21 05:15:53 PDT
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)
Comment 2 2010-03-22 10:17:21 PDT
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
Comment 3 2010-03-22 11:15:40 PDT
(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
Comment 4 2010-03-22 11:16:42 PDT
(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)
Comment 5 2010-03-22 11:18:28 PDT
I'll upload the commit-bot's output shortly.
Eric Seidel (no email)
Comment 6 2010-03-22 12:24:31 PDT
Created attachment 51328 [details] pretty diff from failure on commit bot Here is the failure from the commit bot.
Brady Eidson
Comment 8 2010-03-22 14:45:42 PDT
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)
Comment 9 2010-03-22 14:53:00 PDT
Created attachment 51359 [details] Patch for landing
Eric Seidel (no email)
Comment 10 2010-03-22 14:54:15 PDT
Created attachment 51360 [details] Patch for landing
Eric Seidel (no email)
Comment 11 2010-03-22 14:54:58 PDT
Thanks for the diagnosis Brady.
Brady Eidson
Comment 12 2010-03-22 15:07:43 PDT
(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 13 2010-03-22 22:32:49 PDT
Comment on attachment 51360 [details] Patch for landing Clearing flags on attachment: 51360 Committed r56378: <http://trac.webkit.org/changeset/56378>
WebKit Commit Bot
Comment 14 2010-03-22 22:32:54 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.