Summary: | ASSERTION FAILED: !m_processes[i] || *m_processes[i] == process in MessagePortChannel::entanglePortWithProcess() | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Chris Dumez <cdumez> | ||||
Component: | Service Workers | Assignee: | Chris Dumez <cdumez> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | ap, beidson, commit-queue, ggaren, jlewis3, rniwa, ryanhaddad, webkit-bug-importer, youennf | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=182311 | ||||||
Attachments: |
|
Description
Chris Dumez
2018-01-24 09:55:44 PST
According flakiness dashboard, imported/w3c/web-platform-tests/service-workers/service-worker/extendable-event-async-waituntil.https.html is very flaky due to that. See https://build.webkit.org/results/Apple%20High%20Sierra%20Debug%20WK2%20(Tests)/r227533%20(1762)/results.html for instance. Taking a look I absolutely cannot reproduce no matter how I stress test my WKTR. That said, I can see how this can happen in SW-land where calls to entangle and disentangle are coming in from different processes. 1 - Web process sends a "disentangle" message to the UI process 2 - Web process sends a postMessage to the StorageProcess with the port as a payload. 3 - Storage process forwards that message along to the SW process with the payload. 4 - ServerWorker process gets the message and then sends the UI process the "entangle" message For some reason the disentangle sent in #1 is slow to go out - and in fact not even received by the UI process for awhile. And then #2, #3, and #4 happen pretty quickly. In this scenario the #4 entangle is received before the #1 disentangle, triggering the ASSERT (Note, it also means the disentangle will come in later in a release build and wreck havoc, rendering messages undeliverable) Bummer. If we move to a model where the UI process *is* the storage process, this would actually go away. (That's obviously not the short term fix) Created attachment 334048 [details]
Patch
Comment on attachment 334048 [details] Patch Clearing flags on attachment: 334048 Committed r228564: <https://trac.webkit.org/changeset/228564> All reviewed patches have been landed. Closing bug. I have just looked at the flakiness dashboard and so far no crash yet with this fix. imported/w3c/web-platform-tests/service-workers/service-worker/extendable-event-async-waituntil.https.html test was the flakiest by far and has done 4 runs without crash and with the fix at this point. *** Bug 182341 has been marked as a duplicate of this bug. *** |