Currently, the RemoteRenderingBackendProxy::DidCreateWakeUpSemaphoreForDisplayListStream() message is dispatched in the RemoteRenderingBackend constructor before the underlying connection is open. The connection exists, it's valid, just not open, so the message isn't sent but it's still kept in the outgoing messages queue. There's no other message dispatched on this connection afterwards, meaning the queue doesn't get flushed. So the initial message is never sent, which then causes problems down the line in GPUProcess execution. It's possible to rework things so that the message is sent after the connection is opened, but there's also the question of whether the Unix implementation of IPC::Connection should handle this situation somewhat better.
Created attachment 457890 [details] The workaround
Created attachment 457892 [details] Patch
(In reply to Zan Dobersek from comment #2) > Created attachment 457892 [details] > Patch Turned it into a proper patch. It also includes the RemoteRenderingBackend::startListeningForIPC() method being folded into the constructor.
Comment on attachment 457892 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=457892&action=review > Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:107 > m_streamConnection->open(); This line starts invoking the virtual functions from the other thread. The vptr of the object is set up by the constructor and is not thread-safe, so this cannot happen in the constructor. The bug was fixed in bug 239399
*** This bug has been marked as a duplicate of bug 239399 ***