Bug 158500

Summary: REGRESSION (r201461): LayoutTest storage/indexeddb/database-close-private.html is a flaky failure
Product: WebKit Reporter: Ryan Haddad <ryanhaddad>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: beidson
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 154968    

Description Ryan Haddad 2016-06-07 17:05:59 PDT
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
Comment 1 Alexey Proskuryakov 2016-06-07 18:36:46 PDT
The first failure that I see was in r201466. Very likely caused by <http://trac.webkit.org/projects/webkit/changeset/201461>.
Comment 2 Brady Eidson 2016-06-07 22:55:19 PDT
The test is probably bogus, will check it out in the A.M.
Comment 3 Brady Eidson 2016-06-09 10:29:23 PDT
(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?
Comment 4 Brady Eidson 2016-06-09 10:36:56 PDT
(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.
Comment 5 Brady Eidson 2016-06-11 17:42:50 PDT
*** Bug 158644 has been marked as a duplicate of this bug. ***
Comment 6 Brady Eidson 2016-06-24 11:09:06 PDT
It's obvious how 201461 affected this, and I have a fix.
Comment 7 Brady Eidson 2016-06-24 16:34:45 PDT
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.
Comment 8 Brady Eidson 2016-06-24 16:43:07 PDT
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.
Comment 9 Ryan Haddad 2016-07-12 14:10:43 PDT
Marked test as flaky on Mac in <http://trac.webkit.org/projects/webkit/changeset/203128>