Bug 182054 - ASSERTION FAILED: !m_processes[i] || *m_processes[i] == process in MessagePortChannel::entanglePortWithProcess()
Summary: ASSERTION FAILED: !m_processes[i] || *m_processes[i] == process in MessagePor...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Service Workers (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
: 182341 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-01-24 09:55 PST by Chris Dumez
Modified: 2021-09-17 10:31 PDT (History)
9 users (show)

See Also:


Attachments
Patch (13.33 KB, patch)
2018-02-16 10:04 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2018-01-24 09:55:44 PST
ASSERTION FAILED: !m_processes[i] || *m_processes[i] == process in MessagePortChannel::entanglePortWithProcess():
ERROR: Request to remove client-side ServiceWorkerRegistration from non-existent server-side registration
/Volumes/Data/WebKit/OpenSource/Source/WebCore/workers/service/server/SWServer.cpp(457) : void WebCore::SWServer::removeClientServiceWorkerRegistration(WebCore::SWServer::Connection &, ServiceWorkerRegistrationIdentifier)
ASSERTION FAILED: !m_processes[i] || *m_processes[i] == process
/Volumes/Data/WebKit/OpenSource/Source/WebCore/dom/messageports/MessagePortChannel.cpp(87) : void WebCore::MessagePortChannel::entanglePortWithProcess(const WebCore::MessagePortIdentifier &, ProcessIdentifier)
1   0x10b67001d WTFCrash
2   0x11a67e63c WebCore::MessagePortChannel::entanglePortWithProcess(WebCore::MessagePortIdentifier const&, WTF::ObjectIdentifier<WebCore::ProcessIdentifierType>)
3   0x11a680c93 WebCore::MessagePortChannelRegistry::didEntangleLocalToRemote(WebCore::MessagePortIdentifier const&, WebCore::MessagePortIdentifier const&, WTF::ObjectIdentifier<WebCore::ProcessIdentifierType>)
4   0x10f48c88c WebKit::WebProcessProxy::entangleLocalPortInThisProcessToRemote(WebCore::MessagePortIdentifier const&, WebCore::MessagePortIdentifier const&)
5   0x10f4bc77d void IPC::callMemberFunctionImpl<WebKit::WebProcessProxy, void (WebKit::WebProcessProxy::*)(WebCore::MessagePortIdentifier const&, WebCore::MessagePortIdentifier const&), std::__1::tuple<WebCore::MessagePortIdentifier, WebCore::MessagePortIdentifier>, 0ul, 1ul>(WebKit::WebProcessProxy*, void (WebKit::WebProcessProxy::*)(WebCore::MessagePortIdentifier const&, WebCore::MessagePortIdentifier const&), std::__1::tuple<WebCore::MessagePortIdentifier, WebCore::MessagePortIdentifier>&&, std::__1::integer_sequence<unsigned long, 0ul, 1ul>)
6   0x10f4bc500 void IPC::callMemberFunction<WebKit::WebProcessProxy, void (WebKit::WebProcessProxy::*)(WebCore::MessagePortIdentifier const&, WebCore::MessagePortIdentifier const&), std::__1::tuple<WebCore::MessagePortIdentifier, WebCore::MessagePortIdentifier>, std::__1::integer_sequence<unsigned long, 0ul, 1ul> >(std::__1::tuple<WebCore::MessagePortIdentifier, WebCore::MessagePortIdentifier>&&, WebKit::WebProcessProxy*, void (WebKit::WebProcessProxy::*)(WebCore::MessagePortIdentifier const&, WebCore::MessagePortIdentifier const&))
7   0x10f4ba2f8 void IPC::handleMessage<Messages::WebProcessProxy::EntangleLocalPortInThisProcessToRemote, WebKit::WebProcessProxy, void (WebKit::WebProcessProxy::*)(WebCore::MessagePortIdentifier const&, WebCore::MessagePortIdentifier const&)>(IPC::Decoder&, WebKit::WebProcessProxy*, void (WebKit::WebProcessProxy::*)(WebCore::MessagePortIdentifier const&, WebCore::MessagePortIdentifier const&))
8   0x10f4b8d9a WebKit::WebProcessProxy::didReceiveWebProcessProxyMessage(IPC::Connection&, IPC::Decoder&)
9   0x10f485e49 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
10  0x10f485eb4 non-virtual thunk to WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
11  0x10e8a98d3 IPC::Connection::dispatchMessage(IPC::Decoder&)
12  0x10e89ee38 IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >)
13  0x10e8a9eda IPC::Connection::dispatchOneMessage()
14  0x10e8c245d IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >)::$_14::operator()()
15  0x10e8c23b9 WTF::Function<void ()>::CallableWrapper<IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >)::$_14>::call()
16  0x10b68c16b WTF::Function<void ()>::operator()() const
17  0x10b6d112d WTF::RunLoop::performWork()
18  0x10b6d18e4 WTF::RunLoop::performWork(void*)
19  0x7fff3a301721 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
20  0x7fff3a3bb0ac __CFRunLoopDoSource0
21  0x7fff3a2e4260 __CFRunLoopDoSources0
22  0x7fff3a2e36dd __CFRunLoopRun
23  0x7fff3a2e2f43 CFRunLoopRunSpecific
24  0x7fff3c3b4c16 -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
25  0x10a0105a4 WTR::TestController::platformRunUntil(bool&, double)
26  0x109feaed9 WTR::TestController::runUntil(bool&, double)
27  0x10a0138ba WTR::TestInvocation::invoke()
28  0x109ff3ded WTR::TestController::runTest(char const*)
29  0x109ff4f74 WTR::TestController::runTestingServerLoop()
30  0x109fe58a6 WTR::TestController::run()
31  0x109fe522a WTR::TestController::TestController(int, char const**)


Seems to have happened during this test for me:
imported/w3c/web-platform-tests/service-workers/service-worker/fetch-request-css-base-url.https.html
Comment 1 youenn fablet 2018-01-24 14:21:38 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.
Comment 2 Brady Eidson 2018-01-24 15:03:20 PST
Taking a look
Comment 3 Brady Eidson 2018-01-24 16:44:58 PST
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)
Comment 4 Radar WebKit Bug Importer 2018-01-25 09:17:25 PST
<rdar://problem/36871207>
Comment 5 Chris Dumez 2018-02-16 10:04:18 PST
Created attachment 334048 [details]
Patch
Comment 6 WebKit Commit Bot 2018-02-16 11:05:11 PST
Comment on attachment 334048 [details]
Patch

Clearing flags on attachment: 334048

Committed r228564: <https://trac.webkit.org/changeset/228564>
Comment 7 WebKit Commit Bot 2018-02-16 11:05:13 PST
All reviewed patches have been landed.  Closing bug.
Comment 8 Chris Dumez 2018-02-16 15:35:01 PST
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.
Comment 9 Eric Hutchison 2021-09-17 10:31:41 PDT
*** Bug 182341 has been marked as a duplicate of this bug. ***