158500 2016-06-07 17:05:59 -0700 REGRESSION (r201461): LayoutTest storage/indexeddb/database-close-private.html is a flaky failure 2016-07-12 14:10:43 -0700 1 1 1 Unclassified WebKit WebCore Misc. WebKit Nightly Build Unspecified Unspecified NEW P2 Normal --- 154968 1 ryanhaddad webkit-unassigned beidson oldest_to_newest 1200246 0 ryanhaddad 2016-06-07 17:05:59 -0700 LayoutTest storage/indexeddb/database-close-private.html is a flaky failure First failure seen a week ago around r201494 <https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK1%20(Tests)/r201772%20(13568)/results.html> <http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=storage%2Findexeddb%2Fdatabase-close-private.html> --- /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/storage/indexeddb/database-close-private-expected.txt +++ /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/storage/indexeddb/database-close-private-actual.txt @@ -43,10 +43,8 @@ transaction #2 request successful PASS event.target.result is "value2" -All transactions completed - database deletes should now be unblocked. - delete database unblocked -PASS awaiting_transaction_count is 0 +FAIL awaiting_transaction_count should be 0. Was 1. PASS successfullyParsed is true TEST COMPLETE 1200284 1 ap 2016-06-07 18:36:46 -0700 The first failure that I see was in r201466. Very likely caused by <http://trac.webkit.org/projects/webkit/changeset/201461>. 1200339 2 beidson 2016-06-07 22:55:19 -0700 The test is probably bogus, will check it out in the A.M. 1200878 3 beidson 2016-06-09 10:29:23 -0700 (In reply to comment #0) > LayoutTest storage/indexeddb/database-close-private.html is a flaky failure > > First failure seen a week ago around r201494 > > <https://build.webkit.org/results/Apple%20Yosemite%20Debug%20WK1%20(Tests)/ > r201772%20(13568)/results.html> > <http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard. > html#showAllRuns=true&tests=storage%2Findexeddb%2Fdatabase-close-private. > html> > > --- > /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/ > storage/indexeddb/database-close-private-expected.txt > +++ > /Volumes/Data/slave/yosemite-debug-tests-wk1/build/layout-test-results/ > storage/indexeddb/database-close-private-actual.txt > @@ -43,10 +43,8 @@ > transaction #2 request successful > PASS event.target.result is "value2" > > -All transactions completed - database deletes should now be unblocked. > - > delete database unblocked > -PASS awaiting_transaction_count is 0 > +FAIL awaiting_transaction_count should be 0. Was 1. > PASS successfullyParsed is true > > TEST COMPLETE This is reallllllly weird. The first transaction request *did* finish, as evidenced by the actual results. So why did the count not get lowered? 1200884 4 beidson 2016-06-09 10:36:56 -0700 (In reply to comment #3) > (In reply to comment #0) > > This is reallllllly weird. > > The first transaction request *did* finish, as evidenced by the actual > results. > > So why did the count not get lowered? Oh, duh - The *requests* succeed, but we don't necessarily get the transaction complete event. Okay. Exploring more. 1201670 5 beidson 2016-06-11 17:42:50 -0700 *** Bug 158644 has been marked as a duplicate of this bug. *** 1205150 6 beidson 2016-06-24 11:09:06 -0700 It's obvious how 201461 affected this, and I have a fix. 1205259 7 beidson 2016-06-24 16:34:45 -0700 I created a modified test case that spins up 100 transactions instead of just 2. It's always the same failure more - only 1 hasn't finished. Then I epihanied: This is because the event for the second transaction completing is queued, and not fired, and *then* the delete operation is unblocked before the queued event fires. It can never happen in the DatabaseProcess because of how the IPC races resolves themselves with the in process thread hopping races. - The delete being unblocked will never come in before the transaction complete event fires. This is truly unique to the InProcessIDBServer, which basically spins the main thread run loop to simulate asynchroncity, but much more reliably triggers a case like this. 1205265 8 beidson 2016-06-24 16:43:07 -0700 I have changes to the test itself to make it much more likely to hit (though still not always) And with that I can work on a fix. 1210151 9 ryanhaddad 2016-07-12 14:10:43 -0700 Marked test as flaky on Mac in <http://trac.webkit.org/projects/webkit/changeset/203128>