Increase in app crashes on iOS 17.4

Attaching error log below.

Incident Identifier: 5CE05737-666A-4AD8-9BC5-D3ECD4CE2F71
Distributor ID:      com.apple.AppStore
Hardware Model:      iPhone14,2
Process:             App [482]
Path:                /private/var/containers/Bundle/Application/B0D2B0B9-831F-401F-B00D-E733A35D72BD/App.app/App
Identifier:          uk.co.bbc.cbeebiesplaytimeisland
Version:             9.10.0 (5836)
AppStoreTools:       15E204
AppVariant:          1:iPhone14,2:15
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           uk.co.bbc.cbeebiesplaytimeisland [681]

Date/Time:           2024-05-01 16:47:45.5386 +0100
Launch Time:         2024-04-28 20:20:20.0516 +0100
OS Version:          iPhone OS 17.4.1 (21E236)
Release Type:        User
Baseband Version:    3.50.04
Report Version:      104

Exception Type:  EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: RUNNINGBOARD 0xd00d2bad 

Triggered by Thread:  0


Kernel Triage:
VM - (arg = 0x3) mach_vm_allocate_kernel failed within call to vm_map_enter


Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib        	0x00000001d7301af8 mach_msg2_trap + 8 (:-1)
1   libsystem_kernel.dylib        	0x00000001d7301890 mach_msg2_internal + 80 (mach_msg.c:201)
2   libsystem_kernel.dylib        	0x00000001d73017a8 mach_msg_overwrite + 436 (mach_msg.c:0)
3   libsystem_kernel.dylib        	0x00000001d73015e8 mach_msg + 24 (mach_msg.c:323)
4   CoreFoundation                	0x000000018eddc01c __CFRunLoopServiceMachPort + 160 (CFRunLoop.c:2624)
5   CoreFoundation                	0x000000018edd9f04 __CFRunLoopRun + 1208 (CFRunLoop.c:3007)
6   CoreFoundation                	0x000000018edd9968 CFRunLoopRunSpecific + 608 (CFRunLoop.c:3420)
7   GraphicsServices              	0x00000001d30cf4e0 GSEventRunModal + 164 (GSEvent.c:2196)
8   UIKitCore                     	0x000000019124cedc -[UIApplication _run] + 888 (UIApplication.m:3692)
9   UIKitCore                     	0x000000019124c518 UIApplicationMain + 340 (UIApplication.m:5282)
10  App                           	0x00000001009b03d4 main + 64 (AppDelegate.swift:5)
11  dyld                          	0x00000001b22fad84 start + 2240 (dyldMain.cpp:1298)

Link to crash report: https://www.dropbox.com/scl/fi/1y1hysgp2nq6kzom63u16/crash.txt?rlkey=ddyzp2vdgmlbqteeix8xgu8mt&st=pmxs7ygm&dl=0

Note the 0xd00d2bad (‘dude, too bad’) exception code. That’s discussed (in very vague terms) in this doc. I’ll try to expand on that here, but be warned that it’s impossible to discuss this without getting deep into iOS implementation details. This stuff changes regularly, so don’t ship code that depends on any of the following.

First, I want to define the term assertion. In this context, I’m using it per the definition in UIApplication Background Task Notes.

Second, I want to talk about runningboardd. This is actually present on macOS as well, and there we have man pages! The runningboardd man page says:

runningboardd is a daemon that manages process assertions to ensure those processes are kept in the appropriate state while assertions are in effect.

As you can see, it’s using assertion in the same way I am (-:

The ‘dude, too bad’ crash indicates that runningboardd has killed your process because it’s using too many assertions. The tricky thing about this, and the reason why the above-mentioned doc is so vague, is that there isn’t a one-to-one correlation between APIs called by you and the number of assertions taken out by the system frameworks. It is, as is often the case, complicated.

Having said that, it’s likely that WebKit is involved. Consider this backtrace:

Thread 7 name:
Thread 7:
0  libobjc.A.dylib       … objc_msgSend + 40 (:-1)
1  Foundation            … -[NSString(NSCFAdditions) _encodingCantBeStoredInEightBitCFString] + 20 (NSCFString.…
2  CoreFoundation        … CFStringAppend + 376 (CFString.c:5930)
3  CoreFoundation        … __CFStringAppendFormatCore + 10964 (CFString.c:9187)
4  CoreFoundation        … _CFStringCreateWithFormatAndArgumentsReturningMetadata + 184 (CFString.c:2030)
5  CoreFoundation        … _CFStringCreateWithFormatAndArgumentsAux2 + 44 (CFString.c:2022)
6  Foundation            … -[NSString initWithFormat:] + 52 (NSString.m:1974)
7  RunningBoardServices  … -[RBSAssertionDescriptor description] + 112 (RBSAssertionDescriptor.m:77)
8  Foundation            … _NS_os_log_callback + 284 (NSPlatform.m:206)
9  libsystem_trace.dylib … _os_log_fmt_flatten_NSCF + 64 (format.m:60)
10 libsystem_trace.dylib … _os_log_fmt_flatten_object + 220 (format.m:322)
11 libsystem_trace.dylib … _os_log_impl_flatten_and_send + 1864 (log.c:2672)
12 libsystem_trace.dylib … _os_log + 168 (log.c:2783)
13 libsystem_trace.dylib … _os_log_impl + 28 (log.c:2801)
14 RunningBoardServices  … -[RBSConnection acquireAssertion:error:] + 160 (RBSConnection.m:277)
15 RunningBoardServices  … -[RBSAssertion acquireWithError:] + 176 (RBSAssertion.m:93)
16 ServiceExtensions     … specialized static _Capability.acquireAssertion(process:environmentIdentifier:attrib…
17 ServiceExtensions     … _Capability.AssertionCapability.grant(to:) + 328 (Capabilities.swift:283)
18 ServiceExtensions     … specialized _ExtensionProcess.grant(capabilities:) + 592 (:-1)
19 ServiceExtensions     … protocol witness for _ExtensionProcess.grant(capability:) in conformance _ContentPro…
20 ServiceExtensions     … _SEExtensionProcess.grant(capabilities:) + 204 (:-1)
21 ServiceExtensions     … _SEExtensionProcess.grant(capability:) + 16 (:-1)
22 ServiceExtensions     … @objc _SEExtensionProcess.grant(capabilities:) + 76 (:-1)
23 WebKit                … WebKit::ProcessAssertion::acquireSync() + 300 (ProcessAssertionCocoa.mm:475)
24 WebKit                … WTF::Detail::CallableWrapper<WebKit::ProcessAssertion::acquireAsync(WTF::CompletionH…
25 JavaScriptCore        … void WTF::dispatchWorkItem<WTF::(anonymous namespace)::DispatchWorkItem>(void*) + 60…
26 libdispatch.dylib     … _dispatch_client_callout + 20 (object.m:576)
27 libdispatch.dylib     … _dispatch_lane_serial_drain + 748 (queue.c:3900)
28 libdispatch.dylib     … _dispatch_lane_invoke + 380 (queue.c:3991)
29 libdispatch.dylib     … _dispatch_root_queue_drain_deferred_wlh + 288 (queue.c:6998)
30 libdispatch.dylib     … _dispatch_workloop_worker_thread + 404 (queue.c:6592)
31 libsystem_pthread.dyli… _pthread_wqthread + 288 (pthread.c:2665)
32 libsystem_pthread.dyli… start_wqthread + 8 (:-1)

You can see stuff related to runningboardd in frames 7, 14, and 15, and stuff related to WebKit in a bunch of other frames.

Now, that does not mean that WebKit is at fault. It could be that some other code put your app into this state and WebKit just happened to be the one that noticed.

Coming back to that graph you posted, I presume that your seeing this crash disparity between OS releases that are all running the same version of your app? If so, I think the next step is for you to file a bug about this.

If you have access to a device that crashed in this way, make sure to include a sysdiagnose log from it.

Please post your bug number, just for the record.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Any SwiftUI in your app @agnel_joseph ?

The best thing to do will be to reach out to the team @ Capacitor and file a bug with them.