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
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?
(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...
(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?).
Created attachment 436298 [details] Patch
(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.
Committed r281511 (240884@main): <https://commits.webkit.org/240884@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 436298 [details].
<rdar://problem/82303595>