238391 – With DOM Rendering in GPUP enabled, tests sometimes assert in GPUConnectionToWebProcess::didReceiveMessage()

Bug 238391 - With DOM Rendering in GPUP enabled, tests sometimes assert in GPUConnectionToWebProcess::didReceiveMessage()

Summary: With DOM Rendering in GPUP enabled, tests sometimes assert in GPUConnectionTo...

Status:	RESOLVED CONFIGURATION CHANGED

Alias:	None

Product:	WebKit
Classification:	Unclassified
Component:	WebKit Process Model (show other bugs)
Version:	Safari Technology Preview
Hardware:	Unspecified Unspecified

Importance:	P2 Normal
Assignee:	Nobody

URL:
Keywords:	InRadar

Depends on:
Blocks:

Reported:	2022-03-25 14:12 PDT by Simon Fraser (smfr)
Modified:	2022-04-11 23:41 PDT (History)
CC List:	4 users (show)

See Also:	237674

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Simon Fraser (smfr) 2022-03-25 14:12:38 PDT

Running fast/css tests in iOS simulator with DOM Rendering enabled, tests will sometimes assert here:

14:08:21.497 71433   1   0x14233d1a9 WTFCrash
14:08:21.497 71433   2   0x12ddf0e4b WTFCrashWithInfo(int, char const*, char const*, int)
14:08:21.497 71433   3   0x12e85e412 WebKit::GPUConnectionToWebProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&)
14:08:21.497 71433   4   0x12f1e93a0 IPC::Connection::dispatchMessage(IPC::Decoder&)
14:08:21.497 71433   5   0x12f1e9a95 IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >)
14:08:21.497 71433   6   0x12f1e3003 IPC::Connection::SyncMessageState::ConnectionAndIncomingMessage::dispatch()
14:08:21.497 71433   7   0x12f1e3298 IPC::Connection::SyncMessageState::dispatchMessagesAndResetDidScheduleDispatchMessagesForConnection(IPC::Connection&)
14:08:21.497 71433   8   0x12f1fa8ec IPC::Connection::SyncMessageState::processIncomingMessage(IPC::Connection&, std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >&)::$_5::operator()()
14:08:21.497 71433   9   0x12f1fa819 WTF::Detail::CallableWrapper<IPC::Connection::SyncMessageState::processIncomingMessage(IPC::Connection&, std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >&)::$_5, void>::call()
14:08:21.497 71433   10  0x142368852 WTF::Function<void ()>::operator()() const
14:08:21.497 71433   11  0x1423f2602 WTF::RunLoop::performWork()
14:08:21.497 71433   12  0x1423f5f2e WTF::RunLoop::performWork(void*)
14:08:21.497 71433   13  0x10a468833 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
14:08:21.497 71433   14  0x10a46872b __CFRunLoopDoSource0
14:08:21.497 71433   15  0x10a467bf8 __CFRunLoopDoSources0
14:08:21.497 71433   16  0x10a4622f4 __CFRunLoopRun
14:08:21.497 71433   17  0x10a461a90 CFRunLoopRunSpecific
14:08:21.497 71433   18  0x10adb1e31 -[NSRunLoop(NSRunLoop) runMode:beforeDate:]
14:08:21.497 71433   19  0x10adb204f -[NSRunLoop(NSRunLoop) run]
14:08:21.497 71433   20  0x10b8bffeb _xpc_objc_main
14:08:21.497 71433   21  0x10b8c1fd4 xpc_main
14:08:21.497 71433   22  0x12ea9c3ea WebKit::XPCServiceMain(int, char const**)
14:08:21.497 71433   23  0x1309acdcb WKXPCServiceMain
14:08:21.497 71433   24  0x109e14d32 main
14:08:21.497 71433   25  0x10a02af21
14:08:21.497 71433   26  0x1197f150e

Comment 1 Simon Fraser (smfr) 2022-03-25 14:13:06 PDT

Logging says:

14:08:21.496 71433 worker/0 fast/css/computed-image-width-with-percent-height-expected.html crashed, (stderr lines):
14:08:21.496 71433   StreamServerConnection::dispatchOutOfStreamMessage - no receiver for destination 8
14:08:21.496 71433   RemoteRenderingBackendProxy 0x7fba92a06c50 createRemoteImageBuffer 2854
14:08:21.496 71433   RemoteRenderingBackend 0x1540840c0 createImageBufferWithQualifiedIdentifier 2854
14:08:21.496 71433   RemoteDisplayListRecorder 0x154048950 RemoteDisplayListRecorder - RemoteRenderingBackend 0x1540840c0
14:08:21.496 71433   RemoteDisplayListRecorder 0x154048950 startListeningForIPC destination 2854
14:08:21.496 71433   StreamServerConnectionBase::startReceivingMessagesImpl destination 2854
14:08:21.496 71433    main thread: addMessageReceiveQueue destination 2854
14:08:21.496 71433   MessageReceiveQueueMap 0x15403c3d0 addImpl receiver RemoteDisplayListRecorder destination 2854
14:08:21.496 71433    done destination 2854
14:08:21.496 71433   create RemoteImageBuffer 0x15409c100 2854
14:08:21.496 71433   StreamServerConnection 0x154020220 processSetStreamDestinationID - current 8, new 2854
14:08:21.496 71433   StreamServerConnection 0x154020220 processSetStreamDestinationID - current 2854, new 8
14:08:21.496 71433   StreamServerConnection::dispatchOutOfStreamMessage - no receiver for destination 8
14:08:21.496 71433   StreamServerConnection::dispatchOutOfStreamMessage - no receiver for destination 8
14:08:21.496 71433   StreamServerConnection::dispatchOutOfStreamMessage - no receiver for destination 8
14:08:21.496 71433   StreamServerConnection 0x154020220 processSetStreamDestinationID - current 8, new 2851
14:08:21.496 71433   StreamServerConnection 0x154020220 processSetStreamDestinationID - current 2851, new 8
14:08:21.496 71433   StreamServerConnection 0x154020220 processSetStreamDestinationID - current 8, new 2854
14:08:21.496 71433   StreamServerConnection 0x154020220 processSetStreamDestinationID - current 2854, new 8
14:08:21.496 71433   destroy RemoteImageBuffer 0x15409c100 2854
14:08:21.496 71433   StreamServerConnection::dispatchOutOfStreamMessage - no receiver for destination 8
14:08:21.496 71433   MessageReceiveQueueMap 0x15403c3d0 remove receiver RemoteDisplayListRecorder destination 2854
14:08:21.496 71433   RemoteRenderingBackendProxy 0x7fba92a06c50 createRemoteImageBuffer 2860
14:08:21.496 71433   RemoteRenderingBackend 0x1540840c0 createImageBufferWithQualifiedIdentifier 2860
14:08:21.496 71433   RemoteDisplayListRecorder 0x154048a90 RemoteDisplayListRecorder - RemoteRenderingBackend 0x1540840c0
14:08:21.496 71433   RemoteDisplayListRecorder 0x154048a90 startListeningForIPC destination 2860
14:08:21.497 71433   StreamServerConnectionBase::startReceivingMessagesImpl destination 2860
14:08:21.497 71433    main thread: addMessageReceiveQueue destination 2860
14:08:21.497 71433   MessageReceiveQueueMap 0x15403c3d0 addImpl receiver RemoteDisplayListRecorder destination 2860
14:08:21.497 71433    done destination 2860
14:08:21.497 71433   create RemoteImageBuffer 0x15409c180 2860
14:08:21.497 71433   StreamServerConnection 0x154020220 processSetStreamDestinationID - current 8, new 2860
14:08:21.497 71433   StreamServerConnection 0x154020220 processSetStreamDestinationID - current 2860, new 2851
14:08:21.497 71433   StreamServerConnection 0x154020220 processSetStreamDestinationID - current 2851, new 8
14:08:21.497 71433   destroy RemoteImageBuffer 0x15409c980 2851
14:08:21.497 71433   MessageReceiveQueueMap 0x15403c3d0 remove receiver RemoteDisplayListRecorder destination 2851
14:08:21.497 71433   StreamServerConnection::dispatchOutOfStreamMessage - no receiver for destination 8
14:08:21.497 71433   RemoteRenderingBackendProxy 0x7fba92a06c50 createRemoteImageBuffer 2867
14:08:21.497 71433   RemoteRenderingBackend 0x1540840c0 createImageBufferWithQualifiedIdentifier 2867
14:08:21.497 71433   StreamClientConnection::send - failed to send inline message to stream
14:08:21.497 71433   SyncMessageState::processIncomingMessage: RemoteDisplayListRecorder message will be dispatched to the main thread
14:08:21.497 71433   Unhandled message RemoteDisplayListRecorder_DrawGlyphs to 2867
14:08:21.497 71433   SHOULD NEVER BE REACHED

Comment 2 Simon Fraser (smfr) 2022-03-25 14:15:16 PDT

So:
1. StreamClientConnection fails to send an "createRemoteImageBuffer" inline message in-stream, and falls back to  out-of-stream
2. This message gets handled in SyncMessageState::processIncomingMessage(), so we bounce it to the main thread
3. We then receive a in-stream message that tries to target this image buffer, but its IPC receiver hasn't been registered yet.

Comment 3 Radar WebKit Bug Importer 2022-03-25 14:15:47 PDT

<rdar://problem/90856029>

Comment 4 Simon Fraser (smfr) 2022-03-25 14:29:47 PDT

This is with the fix for bug 237674.

MessageReceiveQueueMap::get() has special code for the pair<receiverName, 0> so that patch may have changed behavior.

Comment 5 Simon Fraser (smfr) 2022-03-25 15:21:51 PDT

The patch in bug 237674 ensured that we never use a std::pair<receiverName, 0> because you can only have one per IPC::Connection, and we need these per RemoteRenderingBackend.

So I'm not sure if it's valid for MessageReceiveQueueMap::get() to use the destinationID of 0 when looking for entries in the queues.

Comment 6 Kimmo Kinnunen 2022-03-28 01:19:47 PDT

you're seeing this problem because you removed the very thing that "fixed" this.

Comment 7 Simon Fraser (smfr) 2022-03-28 09:48:00 PDT

It wasn't at all clear that zero was a magic number.