Bug 174729 - Crash in many WebKit apps marking a connection invalid under Messages::NetworkProcessProxy::canAuthenticateAgainstProtectionSpace
Summary: Crash in many WebKit apps marking a connection invalid under Messages::Networ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Brady Eidson
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-07-21 15:17 PDT by Brady Eidson
Modified: 2018-09-19 10:19 PDT (History)
3 users (show)

See Also:


Attachments
Patch (3.29 KB, patch)
2017-07-21 15:26 PDT, Brady Eidson
no flags Details | Formatted Diff | Diff
Patch (3.28 KB, patch)
2017-07-21 15:55 PDT, Brady Eidson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brady Eidson 2017-07-21 15:17:29 PDT
Crash in many WebKit apps marking a connection invalid under Messages::NetworkProcessProxy::canAuthenticateAgainstProtectionSpace

This is the top of the crash stack:
IPC::Connection::markCurrentlyDispatchedMessageAsInvalid() <==
WebPageProxy::canAuthenticateAgainstProtectionSpace
NetworkProcessProxy::CanAuthenticateAgainstProtectionSpace
void IPC::handleMessage<Messages::NetworkProcessProxy::CanAuthenticateAgainstProtectionSpace, WebKit::NetworkProcessProxy...

NetworkProcessProxy checks the validity of the WebPageProxy but not the WebFrameProxy.

Then the WebPageProxy message checks the frameID, finds it is invalid, then tries to mark its connection invalid... but it doesn't have a connection.

On the surface this seems bizarre, but it's an okay state to be in. The NetworkingProcess cannot possible know about the validity of WebPage and WebFrame identifiers by the time it messages the UIProcess directly for this CanAuthenticateAgainstProtectionSpace event.

Previously, the CanAuthenticateAgainstProtectionSpace event went from Network -> Web -> UIProcess and, in that case, the message check handling it was valid.
But since we short circuited the WebProcess out of handling this event, the message check no longer holds.

The NetworkProcessProxy just needs to validate the ids up front.

<rdar://problem/28822272>
Comment 1 Brady Eidson 2017-07-21 15:26:18 PDT
Created attachment 316127 [details]
Patch
Comment 2 WebKit Commit Bot 2017-07-21 15:49:52 PDT
Comment on attachment 316127 [details]
Patch

Rejecting attachment 316127 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-03', 'build', '--no-clean', '--no-update', '--build-style=release', '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
 -c /Volumes/Data/EWS/WebKit/Source/WebKit/UIProcess/ios/forms/WKFileUploadPanel.mm -o /Volumes/Data/EWS/WebKit/WebKitBuild/WebKit.build/Release/WebKit.build/Objects-normal/x86_64/WKFileUploadPanel.o

** BUILD FAILED **


The following build commands failed:
	CompileC /Volumes/Data/EWS/WebKit/WebKitBuild/WebKit.build/Release/WebKit.build/Objects-normal/x86_64/NetworkProcessProxy.o UIProcess/Network/NetworkProcessProxy.cpp normal x86_64 c++ com.apple.compilers.llvm.clang.1_0.compiler
(1 failure)

Full output: http://webkit-queues.webkit.org/results/4163957
Comment 3 Brady Eidson 2017-07-21 15:55:29 PDT
Created attachment 316132 [details]
Patch
Comment 4 WebKit Commit Bot 2017-07-21 17:15:03 PDT
Comment on attachment 316132 [details]
Patch

Clearing flags on attachment: 316132

Committed r219754: <http://trac.webkit.org/changeset/219754>
Comment 5 WebKit Commit Bot 2017-07-21 17:15:05 PDT
All reviewed patches have been landed.  Closing bug.