229444 2021-08-24 08:29:39 -0700 Crash in [RBSTarget targetWithPid:] during WebProcessProxy::shutDown 2021-08-24 12:12:20 -0700 1 1 1 Unclassified WebKit WebKit2 WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 ajuma cdumez achristensen cdumez darin ggaren kkinnunen sihui_liu webkit-bug-importer oldest_to_newest 1786743 0 ajuma 2021-08-24 08:29:39 -0700 Chrome for iOS is getting crash reports with the following stack, including on iOS 15 beta 6. The thrown exception is: 'must specify a valid pid'. Since r259717 ensures the pid is non-zero, perhaps there are cases where the process has already died by the time we try to take an assertion. 0x000000018fa2e708 (CoreFoundation + 0x00129708) __exceptionPreprocess 0x00000001a45387a4 (libobjc.A.dylib + 0x000287a4) objc_exception_throw 0x000000018f9303b4 (CoreFoundation + 0x0002b3b4) +[NSException raise:format:arguments:] 0x0000000190d064c0 (Foundation + 0x0007e4c0) -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] 0x0000000198e25188 (RunningBoardServices + 0x00027188) +[RBSTarget targetWithProcessIdentifier:] 0x0000000198e2507c (RunningBoardServices + 0x0002707c) +[RBSTarget targetWithPid:] 0x000000019c203588 (WebKit + 0x003eb588) WebKit::ProcessAssertion::ProcessAssertion(int, WTF::String const&, WebKit::ProcessAssertionType) 0x000000019c203f2c (WebKit + 0x003ebf2c) WebKit::ProcessAndUIAssertion::ProcessAndUIAssertion(int, WTF::String const&, WebKit::ProcessAssertionType) 0x000000019bf1fb78 (WebKit + 0x00107b78) IPC::ConnectionTerminationWatchdog::ConnectionTerminationWatchdog(WTF::OSObjectPtr<NSObject<OS_xpc_object>*>&, WTF::Seconds) 0x000000019bf1c0c0 (WebKit + 0x001040c0) IPC::ConnectionTerminationWatchdog::createConnectionTerminationWatchdog(WTF::OSObjectPtr<NSObject<OS_xpc_object>*>&, WTF::Seconds) 0x000000019c11e378 (WebKit + 0x00306378) WebKit::AuxiliaryProcessProxy::shutDownProcess() 0x000000019c1da3f0 (WebKit + 0x003c23f0) WebKit::WebProcessProxy::shutDown() 0x000000019c1e7b48 (WebKit + 0x003cfb48) WebKit::WebProcessProxy::processDidTerminateOrFailedToLaunch() 0x000000019c1e78c0 (WebKit + 0x003cf8c0) WebKit::WebProcessProxy::didClose(IPC::Connection&) 0x000000019be4c524 (WebKit + 0x00034524) WTF::Detail::CallableWrapper<IPC::Connection::connectionDidClose()::$_6, void>::call() 0x0000000199dae15c (JavaScriptCore + 0x00f6515c) WTF::RunLoop::performWork() 0x0000000199daf12c (JavaScriptCore + 0x00f6612c) WTF::RunLoop::performWork(void*) 0x000000018f9a898c (CoreFoundation + 0x000a398c) __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 0x000000018f9a8888 (CoreFoundation + 0x000a3888) __CFRunLoopDoSource0 0x000000018f9a7b8c (CoreFoundation + 0x000a2b8c) __CFRunLoopDoSources0 0x000000018f9a1b6c (CoreFoundation + 0x0009cb6c) __CFRunLoopRun 0x000000018f9a1304 (CoreFoundation + 0x0009c304) CFRunLoopRunSpecific 0x00000001a7024730 (GraphicsServices + 0x00003730) GSEventRunModal 0x000000019241f758 (UIKitCore + 0x00bca758) -[UIApplication _run] 0x0000000192424fc8 (UIKitCore + 0x00bcffc8) UIApplicationMain 0x00000001007d0bac (Chrome -chrome_exe_main.mm:65) main 0x000000018f65dcf4 (libdyld.dylib + 0x00001cf4) start 1786745 1 cdumez 2021-08-24 08:50:55 -0700 I have just discussed this with a RunningBoard engineer. The most likely explanation is that the pid is < 0 (which is possible since pid_t is an int on our Darwin). We get the pid from xpc_connection_get_pid() and I guess this could theoretically return a negative PID (maybe in case of error when the process has already exited). I think we should tweak the PID check on WebKit side to early return if pid <= 0 (instead of doing an early return when !pid). Are you able to write up the patch? 1786748 2 cdumez 2021-08-24 08:51:43 -0700 (In reply to Chris Dumez from comment #1) > I have just discussed this with a RunningBoard engineer. The most likely > explanation is that the pid is < 0 (which is possible since pid_t is an int > on our Darwin). We get the pid from xpc_connection_get_pid() and I guess > this could theoretically return a negative PID (maybe in case of error when > the process has already exited). > > I think we should tweak the PID check on WebKit side to early return if pid > <= 0 (instead of doing an early return when !pid). > > Are you able to write up the patch? By the way, I haven't received such reports for MobileSafari yet, which is a bit odd. I have no idea what Chrome could be doing differently to cause this... 1786749 3 cdumez 2021-08-24 08:55:32 -0700 (In reply to Chris Dumez from comment #2) > (In reply to Chris Dumez from comment #1) > > I have just discussed this with a RunningBoard engineer. The most likely > > explanation is that the pid is < 0 (which is possible since pid_t is an int > > on our Darwin). We get the pid from xpc_connection_get_pid() and I guess > > this could theoretically return a negative PID (maybe in case of error when > > the process has already exited). > > > > I think we should tweak the PID check on WebKit side to early return if pid > > <= 0 (instead of doing an early return when !pid). > > > > Are you able to write up the patch? > > By the way, I haven't received such reports for MobileSafari yet, which is a > bit odd. I have no idea what Chrome could be doing differently to cause > this... Do you know when this crash started for Chrome? And could you give us an idea of the frequency (i.e. is it a top crash?). 1786767 4 436298 cdumez 2021-08-24 09:46:24 -0700 Created attachment 436298 Patch 1786781 5 ajuma 2021-08-24 10:07:56 -0700 (In reply to Chris Dumez from comment #3) > (In reply to Chris Dumez from comment #2) > > (In reply to Chris Dumez from comment #1) > > > I have just discussed this with a RunningBoard engineer. The most likely > > > explanation is that the pid is < 0 (which is possible since pid_t is an int > > > on our Darwin). We get the pid from xpc_connection_get_pid() and I guess > > > this could theoretically return a negative PID (maybe in case of error when > > > the process has already exited). > > > > > > I think we should tweak the PID check on WebKit side to early return if pid > > > <= 0 (instead of doing an early return when !pid). > > > > > > Are you able to write up the patch? > > > > By the way, I haven't received such reports for MobileSafari yet, which is a > > bit odd. I have no idea what Chrome could be doing differently to cause > > this... > > Do you know when this crash started for Chrome? And could you give us an > idea of the frequency (i.e. is it a top crash?). We started getting this crash in iOS 14.0 (ideally we'd have filed a WebKit bug earlier but it somehow fell through the cracks until now). It represents about 0.22% of all crashes for the current version of Chrome, so it's not a top crash but it's not completely rare either. 1786876 6 ews-feeder 2021-08-24 12:11:22 -0700 Committed r281511 (240884@main): <https://commits.webkit.org/240884@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 436298. 1786877 7 webkit-bug-importer 2021-08-24 12:12:20 -0700 <rdar://problem/82303595> 436298 2021-08-24 09:46:24 -0700 2021-08-24 12:11:23 -0700 Patch bug-229444-20210824094623.patch text/plain 2200 cdumez U3VidmVyc2lvbiBSZXZpc2lvbjogMjgxNDk1CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L0No YW5nZUxvZyBiL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCmluZGV4IGFmMDY1NzMyNGI4ZDQ5Y2Fi N2VhYjgxNmYxODJlYjdjMDgxZTM0YzQuLjM1MDJjNGM0NWZlZjQ2ZGI4NjY1NDc2M2Q5ZGY5Yjdi ZTZjMDI1MGIgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvQ2hhbmdlTG9nCisrKyBiL1NvdXJj ZS9XZWJLaXQvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTkgQEAKKzIwMjEtMDgtMjQgIENocmlzIER1 bWV6ICA8Y2R1bWV6QGFwcGxlLmNvbT4KKworICAgICAgICBDcmFzaCBpbiBbUkJTVGFyZ2V0IHRh cmdldFdpdGhQaWQ6XSBkdXJpbmcgV2ViUHJvY2Vzc1Byb3h5OjpzaHV0RG93bgorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjI5NDQ0CisKKyAgICAgICAg UmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgSXQgYXBwZWFycyB4cGNfY29u bmVjdGlvbl9nZXRfcGlkKCkgbWF5IGJlIGFibGUgdG8gcmV0dXJuIGEgUElEIHRoYXQgaXMgbGVz cyB0aGFuIDAKKyAgICAgICAgKGxpa2VseSB3aGVuIHRoZSBwcm9jZXNzIGhhcyBqdXN0IGV4aXRl ZCkgYW5kIHRoaXMgY2F1c2VzIFJ1bm5pbmdCb2FyZCB0byB0aHJvdyBhbgorICAgICAgICBleGNl cHRpb24gYmVjYXVzZSB0aGUgUElEIGlzIGludmFsaWQuIFR3ZWFrIHRoZSBXZWJLaXQgUElEIHZh bGlkYXRpb24gdG8gdXNlICc+PSAwJworICAgICAgICBpbnN0ZWFkIG9mIHNpbXBseSAnIT0gMCcs IHNvIHRoYXQgb3VyIHZhbGlkYXRpb24gaXMgaWRlbnRpY2FsIHRvIHRoZSBvbmUgdXNlZCBieQor ICAgICAgICBSdW5uaW5nQm9hcmQuCisKKyAgICAgICAgKiBVSVByb2Nlc3MvaW9zL1Byb2Nlc3NB c3NlcnRpb25JT1MubW06CisgICAgICAgIChXZWJLaXQ6OlByb2Nlc3NBc3NlcnRpb246OlByb2Nl c3NBc3NlcnRpb24pOgorCiAyMDIxLTA4LTI0ICBBZHJpYW4gUGVyZXogZGUgQ2FzdHJvICA8YXBl cmV6QGlnYWxpYS5jb20+CiAKICAgICAgICAgTm9uLXVuaWZpZWQgYnVpbGQgZml4ZXMsIGxhdGUg QXVndXN0IDIwMjEKZGlmZiAtLWdpdCBhL1NvdXJjZS9XZWJLaXQvVUlQcm9jZXNzL2lvcy9Qcm9j ZXNzQXNzZXJ0aW9uSU9TLm1tIGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvaW9zL1Byb2Nlc3NB c3NlcnRpb25JT1MubW0KaW5kZXggZTFkNzFiN2FhZDdhYzdkYTYwYjdiMTViYmI2ODc4OGMzOTJl YTEzMi4uZDFiYjM0YThmZmUyM2U3NzBmZTdjZjAyNzQ1NWJiNjdkYWZlYmYzNCAxMDA2NDQKLS0t IGEvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvaW9zL1Byb2Nlc3NBc3NlcnRpb25JT1MubW0KKysr IGIvU291cmNlL1dlYktpdC9VSVByb2Nlc3MvaW9zL1Byb2Nlc3NBc3NlcnRpb25JT1MubW0KQEAg LTMzMSw4ICszMzEsOCBAQCBQcm9jZXNzQXNzZXJ0aW9uOjpQcm9jZXNzQXNzZXJ0aW9uKHBpZF90 IHBpZCwgY29uc3QgU3RyaW5nJiByZWFzb24sIFByb2Nlc3NBc3NlcgogewogICAgIE5TU3RyaW5n ICpydW5uaW5nQm9hcmRBc3NlcnRpb25OYW1lID0gcnVubmluZ0JvYXJkTmFtZUZvckFzc2VydGlv blR5cGUoYXNzZXJ0aW9uVHlwZSk7CiAgICAgQVNTRVJUKHJ1bm5pbmdCb2FyZEFzc2VydGlvbk5h bWUpOwotICAgIGlmICghcGlkKSB7Ci0gICAgICAgIFJFTEVBU0VfTE9HX0VSUk9SKFByb2Nlc3NT dXNwZW5zaW9uLCAiJXAgLSBQcm9jZXNzQXNzZXJ0aW9uOiBGYWlsZWQgdG8gYWNxdWlyZSBSQlMg JXtwdWJsaWN9QCBhc3NlcnRpb24gJyV7cHVibGljfXMnIGZvciBwcm9jZXNzIGJlY2F1c2UgUElE IGlzIGludmFsaWQiLCB0aGlzLCBydW5uaW5nQm9hcmRBc3NlcnRpb25OYW1lLCByZWFzb24udXRm OCgpLmRhdGEoKSk7CisgICAgaWYgKHBpZCA8PSAwKSB7CisgICAgICAgIFJFTEVBU0VfTE9HX0VS Uk9SKFByb2Nlc3NTdXNwZW5zaW9uLCAiJXAgLSBQcm9jZXNzQXNzZXJ0aW9uOiBGYWlsZWQgdG8g YWNxdWlyZSBSQlMgJXtwdWJsaWN9QCBhc3NlcnRpb24gJyV7cHVibGljfXMnIGZvciBwcm9jZXNz IGJlY2F1c2UgUElEICVkIGlzIGludmFsaWQiLCB0aGlzLCBydW5uaW5nQm9hcmRBc3NlcnRpb25O YW1lLCByZWFzb24udXRmOCgpLmRhdGEoKSwgcGlkKTsKICAgICAgICAgbV93YXNJbnZhbGlkYXRl ZCA9IHRydWU7CiAgICAgICAgIHJldHVybjsKICAgICB9Cg==