Bug 229444 – Crash in [RBSTarget targetWithPid:] during WebProcessProxy::shutDown

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Ali Juma]

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

[Chris Dumez]

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?

[Chris Dumez]

(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...

[Chris Dumez]

(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?).

[Chris Dumez]

Created attachment 436298 [details]
Patch

[Ali Juma]

(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.

[EWS]

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].

[Radar WebKit Bug Importer]

<rdar://problem/82303595>