Bug 158500 – REGRESSION (r201461): LayoutTest storage/indexeddb/database-close-private.html is a flaky failure

• Component: WebCore Misc.
• Status: NEW

[Ryan Haddad]

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

[Alexey Proskuryakov]

The first failure that I see was in r201466. Very likely caused by <http://trac.webkit.org/projects/webkit/changeset/201461>.

[Brady Eidson]

The test is probably bogus, will check it out in the A.M.

[Brady Eidson]

(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?

[Brady Eidson]

(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.

[Brady Eidson]

*** Bug 158644 has been marked as a duplicate of this bug. ***

[Brady Eidson]

It's obvious how 201461 affected this, and I have a fix.

[Brady Eidson]

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.

[Brady Eidson]

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.

[Ryan Haddad]

Marked test as flaky on Mac in <http://trac.webkit.org/projects/webkit/changeset/203128>