[Webkit-unassigned] [Bug 232580] [GPU Process] Rendering backend may stop processing IPC stream messages after a sync message timeout

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=232580

--- Comment #1 from Wenson Hsieh <wenson_hsieh at apple.com> ---
(In debug builds, we actually hit this assertion:)

```
if (!currentReceiver) {
    // Valid scenario is when receiver has been removed, but there are messages for it in the buffer.
    // FIXME: Since we do not have a receiver, we don't know how to decode the message.
    // This means we must timeout every receiver in the stream connection.
    // Currently we assert that the receivers are empty, as we only have up to one receiver in
    // a stream connection until possibility of skipping is implemented properly.
    Locker locker { m_receiversLock };
    ASSERT(m_receivers.isEmpty());
    return DispatchResult::HasNoMessages;
}
```

…because the currentReceiverName is `IPC`, but the destination is equal that of the `RemoteRenderingBackend`, and the message name itself is `SyncMessageReply`.

What's happening is:

1. Client sends the sync message (RemoteRenderingBackend::GetDataForImageBuffer, in this case).
   Client then begins waiting for a response under `tryAcquireAll()`.

2. Server receives this message but does not reply in time.

3. About a second later, the client times out while waiting in `tryAcquireAll()`, failing the `sendSync()`.
   Soon afterwards, it sends the next stream message and blocks on `clientWaitSemaphore()` inside `tryAcquire`.

4. Server finally finishes processing `GetDataForImageBuffer` and goes to write SyncMessageReply at offset 0.
   Note that WP has already given up on waiting this reply in (3).
   Server then signals the client waiting semaphore.

5. Client writes the new stream message after the SyncMessageReply.

6. Server runs its processing loop from 0, decodes the SyncMessageReply that it just wrote.
   It then fails to find a suitable message receiver for this message and exits the processing loop early.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211101/37fe02f0/attachment.htm>