Summary: | storage/database-lock-after-reload.html is flakey | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> | ||||
Component: | New Bugs | Assignee: | Eric Seidel (no email) <eric> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | benm, commit-queue, hamaji, simon.fraser | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | OS X 10.5 | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 33289 | ||||||
Attachments: |
|
Description
Eric Seidel (no email)
2009-09-10 14:53:36 PDT
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. :( 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. |