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

[bugzilla-daemon at webkit.org]

Chris Dumez <cdumez at apple.com> has granted Alex Christensen
<achristensen at apple.com>'s request for review:
Bug 204460: Null check callback in
NetworkConnectionToWebProcess::didDeliverMessagePortMessages
https://bugs.webkit.org/show_bug.cgi?id=204460

Attachment 384072: Patch

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




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

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

>>>>> Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp:992
>>>>> +    if (auto callback =
m_messageBatchDeliveryCompletionHandlers.take(messageBatchIdentifier))
>>>> 
>>>> This should not be possible in theory, I think we need to find the root
cause.
>>>> 
>>>> 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.