Bug 185225 - Load hangs if the WebProcess fails to launch
Summary: Load hangs if the WebProcess fails to launch
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-05-02 15:50 PDT by Chris Dumez
Modified: 2018-05-03 12:59 PDT (History)
6 users (show)

See Also:


Attachments
Patch (21.33 KB, patch)
2018-05-02 16:08 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (21.37 KB, patch)
2018-05-03 12:08 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2018-05-02 15:50:21 PDT
Load hangs if the WebProcess fails to launch because we do not attempt to relaunch, nor do we notify the client that we failed to launch the WebProcess.
Also, since WebPageProxy::isValid() returns true while in this state, follow-up loads / reloads do not work and do not relaunch the WebProcess.
Comment 1 Chris Dumez 2018-05-02 15:50:41 PDT
<rdar://problem/38249058>
Comment 2 Chris Dumez 2018-05-02 16:08:10 PDT
Created attachment 339362 [details]
Patch
Comment 3 Geoffrey Garen 2018-05-02 19:45:16 PDT
/Volumes/Data/EWS/WebKit/Tools/TestWebKitAPI/Tests/WebKitCocoa/WebContentProcessDidTerminate.mm:37:8: error: unknown type name '_WKProcessTerminationReason'; did you mean 'WKProcessTerminationReason'?
static _WKProcessTerminationReason expectedCrashReason;
Comment 4 Geoffrey Garen 2018-05-02 19:48:32 PDT
Comment on attachment 339362 [details]
Patch

r=me

Please fix the 32bit build before landing.

Seems bad that one can get into the state where a web process never launches. Why do we believe that a re-launch would succeed in this case, when the original launch failed? Do we need to investigate or log more to learn why the original launch failed?
Comment 5 Ryosuke Niwa 2018-05-02 20:38:12 PDT
Comment on attachment 339362 [details]
Patch

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

> Source/WebKit/UIProcess/Launcher/mac/ProcessLauncherMac.mm:234
> +    xpc_connection_set_event_handler(m_xpcConnection.get(), errorHandler);

xpc_connection_set_event_handler adds the event handler asynchronously so there might be a race here.
See https://trac.webkit.org/changeset/230314
Comment 6 Chris Dumez 2018-05-03 08:57:50 PDT
Comment on attachment 339362 [details]
Patch

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

>> Source/WebKit/UIProcess/Launcher/mac/ProcessLauncherMac.mm:234
>> +    xpc_connection_set_event_handler(m_xpcConnection.get(), errorHandler);
> 
> xpc_connection_set_event_handler adds the event handler asynchronously so there might be a race here.
> See https://trac.webkit.org/changeset/230314

The commit you refer to is about dispatch_source_set_event_handler in IPC code. This is xpc_connection_set_event_handler() in process launching code, which we use only to listen for errors.
Could you please clarify what the issue is here? Do you believe my patch introduced a race? As far as I can tell, I am not not changing the ordering of things here, I merely moved the lambda into its own variable so that I could call it to simulate an error.
Comment 7 Chris Dumez 2018-05-03 12:08:03 PDT
Created attachment 339436 [details]
Patch
Comment 8 WebKit Commit Bot 2018-05-03 12:59:11 PDT
Comment on attachment 339436 [details]
Patch

Clearing flags on attachment: 339436

Committed r231321: <https://trac.webkit.org/changeset/231321>
Comment 9 WebKit Commit Bot 2018-05-03 12:59:12 PDT
All reviewed patches have been landed.  Closing bug.