storage/database-lock-after-reload.html is flakey It has now caused 2 commit-queue runs to fail (patches from bug 27632 and bug 29041). The failing result is: --- /tmp/layout-test-results/storage/database-lock-after-reload-expected.txt 2009-09-10 14:42:33.000000000 -0700 +++ /tmp/layout-test-results/storage/database-lock-after-reload-actual.txt 2009-09-10 14:42:33.000000000 -0700 @@ -1,3 +1,4 @@ Inserting some data +Test failed - database is locked Test part 2 Complete I've not looked through the buildbot logs yet, but I suspect that we'll find a failure of this test on them as well.
DumpRenderTree uses its own separate database storage, right? It wouldn't be using the same storage as Safari? Also DumpRenderTree makes sure to unlock/re-init/whatever the database before running all the tests, right?
(In reply to comment #1) > DumpRenderTree uses its own separate database storage, right? It wouldn't be > using the same storage as Safari? Yes, it should create it's databases in a separate folder to Safari. > Also DumpRenderTree makes sure to unlock/re-init/whatever the database before > running all the tests, right? There's a method on the layoutTestController to clear the databases that should reset everything but I think each test needs to invoke it during setup. database-lock-after-reload does, however. Can we tell from what point the test started to become flakey? It was checked in under r45594 about 2 months ago and as far as I know didn't cause any problems then. Cheers, Ben
Failed again just now: http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r48615%20(5210)/results.html
Unfortunately, we're not tracking flakey tests across time like Chromium does: http://src.chromium.org/viewvc/chrome/trunk/src/webkit/tools/layout_tests/flakiness_dashboard.html so I can't tell you when it started failing.
It looks like sometimes it causes DumpRenderTree to crash! http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r48779%20(5418)/results.html This is even more bad news bears. :(
Bug 30172 may be related.
This failed on Tiger just now: http://build.webkit.org/results/Tiger%20Intel%20Release/r53291%20(7775)/storage/database-lock-after-reload-diffs.txt --- layout-test-results/storage/database-lock-after-reload-expected.txt 2010-01-14 14:58:12.000000000 -0800 +++ layout-test-results/storage/database-lock-after-reload-actual.txt 2010-01-14 14:58:12.000000000 -0800 @@ -1,3 +1 @@ -Inserting some data -Test part 2 Complete
This just failed on Leopard Intel Release as well: http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r53292%20(9385)/storage/database-lock-after-reload-diffs.txt This is vying for most-flakey test. :(
Failed on Tiger again just now: http://build.webkit.org/results/Tiger%20Intel%20Release/r53784%20(8113)/storage/database-lock-after-reload-diffs.txt Same results a seen in comment #7
Another failure: http://build.webkit.org/results/Tiger%20Intel%20Release/r53790%20(8118)/storage/database-lock-after-reload-diffs.txt
Another failure: http://build.webkit.org/results/Leopard%20Intel%20Release%20(Tests)/r54007%20(9995)/storage/database-lock-after-reload-diffs.txt
Created attachment 47642 [details] Patch
Comment on attachment 47642 [details] Patch I totally agree to disable this test until Bug 34506 is closed! This flakiness is alive long time...
Attachment 47642 [details] was posted by a committer and has review+, assigning to Eric Seidel for commit.
Comment on attachment 47642 [details] Patch Rejecting patch 47642 from commit-queue. Failed to run "['/Users/eseidel/Projects/CommitQueue/WebKitTools/Scripts/svn-apply', '--reviewer', 'Shinichiro Hamaji', '--force']" exit_code: 1 patching file LayoutTests/ChangeLog Hunk #1 succeeded at 1 with fuzz 3. patching file LayoutTests/platform/mac/Skipped Hunk #1 FAILED at 101. 1 out of 1 hunk FAILED -- saving rejects to file LayoutTests/platform/mac/Skipped.rej Full output: http://webkit-commit-queue.appspot.com/results/251169
Committed r54540: <http://trac.webkit.org/changeset/54540>
Seems to work now. Going to try unskipping.