[webkit-reviews] review granted: [Bug 204460] Null check callback in NetworkConnectionToWebProcess::didDeliverMessagePortMessages : [Attachment 384072] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Nov 22 11:59:33 PST 2019

Chris Dumez <cdumez at apple.com> has granted Alex Christensen
<achristensen at apple.com>'s request for review:
Bug 204460: Null check callback in

Attachment 384072: Patch


--- Comment #8 from Chris Dumez <cdumez at apple.com> ---
Comment on attachment 384072
  --> https://bugs.webkit.org/attachment.cgi?id=384072

View in context: https://bugs.webkit.org/attachment.cgi?id=384072&action=review

>>>>> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:992
>>>>> +    if (auto callback =
>>>> This should not be possible in theory, I think we need to find the root
>>>> m_messageBatchDeliveryCompletionHandlers is only modified here and in
takeAllMessagesForPort(). So either we're getting an unexpected
didDeliverMessagePortMessages or the NetworkConnectionToWebProcess is stale.
>>> Maybe if the network process crashes in between the
takeAllMessagesForPort() call and the didDeliverMessagePortMessages() one? Then
it'd be a new NetworkConnectionToWebProcess. The WebProcess would send the
DidDeliverMessagePortMessages IPC to the new network process, which does not
know about the takeAllMessagesForPort request.
>> If that's what's doing on, it may be possible to write a test for this.
> I think that's what's going on and that was mentioned in
https://bugs.webkit.org/show_bug.cgi?id=201299#c4 , but there doesn't seem to
be a good way to call _terminateNetworkProcess exactly between these two calls.

Then the ChangeLog should state so. Also maybe a comment in the code indicating
why this can happen.

More information about the webkit-reviews mailing list