RESOLVED FIXED 182054
ASSERTION FAILED: !m_processes[i] || *m_processes[i] == process in MessagePortChannel::entanglePortWithProcess()
https://bugs.webkit.org/show_bug.cgi?id=182054
Summary ASSERTION FAILED: !m_processes[i] || *m_processes[i] == process in MessagePor...
Chris Dumez
Reported 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
Attachments
Patch (13.33 KB, patch)
2018-02-16 10:04 PST, Chris Dumez
no flags
youenn fablet
Comment 1 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.
Brady Eidson
Comment 2 2018-01-24 15:03:20 PST
Taking a look
Brady Eidson
Comment 3 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)
Radar WebKit Bug Importer
Comment 4 2018-01-25 09:17:25 PST
Chris Dumez
Comment 5 2018-02-16 10:04:18 PST
WebKit Commit Bot
Comment 6 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>
WebKit Commit Bot
Comment 7 2018-02-16 11:05:13 PST
All reviewed patches have been landed. Closing bug.
Chris Dumez
Comment 8 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.
Eric Hutchison
Comment 9 2021-09-17 10:31:41 PDT
*** Bug 182341 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.