[Webkit-unassigned] [Bug 219240] New: Calling waitForAndDispatchImmediately<M> on a loop fails when multiple M messages arrive simultaneously

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Nov 21 16:47:44 PST 2020


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

            Bug ID: 219240
           Summary: Calling waitForAndDispatchImmediately<M> on a loop
                    fails when multiple M messages arrive simultaneously
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: wenson_hsieh at apple.com

Fix a race condition in IPC logic, wherein a client that calls waitForAndDispatchImmediately<M>() n times may time out when receiving n messages of type M.

...more concretely:

RemoteImageBufferProxy sync-waits for consecutive `RemoteRenderingBackendProxy::DidFlush` messages, and finishes sync-waiting when the DidFlush message containing the expected flush identifier arrives. The following may occur:

(Main thread): waitForAndDispatchImmediately<RemoteRenderingBackendProxy::DidFlush>()

(IPC thread): receives the first DidFlush message
(IPC thread): sees that the message name matches that of m_waitingForMessage, and signals the main thread

(Main thread): sees that m_waitingForMessage now has a decoder, and nulls out m_waitingForMessage
(Main thread): calls into RemoteRenderingBackendProxy::didFlush() and returns from waitForAndDispatchImmediately

(IPC thread): receives the second DidFlush message
(IPC thread): sees that m_waitingForMessage is null

(Main thread): calls into RemoteRenderingBackendProxy::didFlush() and returns from waitForAndDispatchImmediately
(Main thread): sees that the flush is still pending, so we call waitForAndDispatchImmediately<RemoteRenderingBackendProxy::DidFlush>() again
(Main thread): sees that the incoming messages queue doesn't contain DidFlush, so we wait

(IPC thread): enqueues the incoming DidFlush message onto the main thread (via enqueueIncomingMessage)

...and now the main thread will time out waiting for the RemoteRenderingBackendProxy::DidFlush which is currently sitting in the incoming messages queue :|

-- 
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/20201122/75c0edce/attachment-0001.htm>


More information about the webkit-unassigned mailing list