Bug 165242 - REGRESSION (209168!): IndexedDB.IndexedDBMultiProcess and IndexedDB.WebProcessKillIDBCleanup are timing out
Summary: REGRESSION (209168!): IndexedDB.IndexedDBMultiProcess and IndexedDB.WebProces...
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on:
Blocks: 160306
  Show dependency treegraph
Reported: 2016-11-30 22:01 PST by Brady Eidson
Modified: 2016-11-30 23:06 PST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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:

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