Bug 165242

Summary: REGRESSION (209168!): IndexedDB.IndexedDBMultiProcess and IndexedDB.WebProcessKillIDBCleanup are timing out
Product: WebKit Reporter: Brady Eidson <beidson>
Component: WebCore Misc.Assignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ryanhaddad
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 160306    

Description Brady Eidson 2016-11-30 22:01:41 PST
REGRESSION: IndexedDB.IndexedDBMultiProcess and IndexedDB.WebProcessKillIDBCleanup are timing out

Seems they're timing out reliably in most (if not all) configs.
Comment 1 Brady Eidson 2016-11-30 22:04:05 PST
Trying to track down when this started (probably one of my checkins today)
Comment 2 Brady Eidson 2016-11-30 22:05:49 PST
I can reproduce locally (95% of the time)
Comment 3 Brady Eidson 2016-11-30 22:55:04 PST
Focusing on IndexedDB.IndexedDBMultiProcess locally.

I'm not sure this was related to my changes from today.

The test loads 3 html files serially. Each HTML file is expected to communicate back to the native code via various messages.

The first test is supposed to message back:
1 - That an upgrade transaction started (via the javascript onupgradeneeded event handler)
2 - That the transaction completed (via the javascript oncomplete event handler)
3 - That the open request succeeded (via the javascript onsuccess event handler)

I've verified through code, in no uncertain terms, that each of those 3 events are firing in the correct order.

But when the test hangs, only message #1 and #3 makes it back to native code.
Message #2 is lost somehow.

I've confirmed that event #2 *is firing* and *is being handled*, because I've given it side effects that are observed in message #3... yet message #2 never makes it.
Comment 4 Brady Eidson 2016-11-30 22:55:21 PST
Additionally, this only happens "sometimes", even if it's most of the time.
Comment 5 Brady Eidson 2016-11-30 22:57:46 PST
The event handler in question is as follows:
        event.target.transaction.oncomplete = function() {
            window.webkit.messageHandlers.testHandler.postMessage('Transaction complete');
        }

~95% of the time, that message never gets back to native code.
Sometimes it does.

If I change it to the following:
        sawTransactionComplete = false;
        event.target.transaction.oncomplete = function() {
            window.webkit.messageHandlers.testHandler.postMessage('Transaction complete');
            sawTransactionComplete = true;
        }

... and then pass the value of sawTransactionComplete through to the onsuccess event handler message, native code sees that sawTransactionComplete is in fact true.

If I change it to the following:

        event.target.transaction.oncomplete = function() {
            window.webkit.messageHandlers.testHandler.postMessage('Transaction complete');
            alert("Made it here!");
        }

Then the existence of that alert() call makes the test reliably pass!
Comment 6 Brady Eidson 2016-11-30 23:01:34 PST
Based on the history of this one bot:
https://build.webkit.org/buildslaves/bot165

Revision 209167 worked but revision 209169 failed.

https://trac.webkit.org/changeset/209168 is of course a (surprising) candidate.

Other bots seem to confirm.
Comment 7 Brady Eidson 2016-11-30 23:06:38 PST
Rolled out in https://trac.webkit.org/changeset/209176