ios 17 background crash after receiving notification

Question

hadicrax OP

Created Mar ’24

Replies 3

Boosts 0

Participants 2

Hi,

When our app receive a push notification in killed state (background), it will crash a few seconds after the first time notification banner was shown, and it happened only on ios 17.

From the crash log, It should be a watchdog terminations problem based on https://developer.apple.com/documentation/xcode/identifying-the-cause-of-common-crashes, which might caused by unresponsive UI or network call.

Our app use a hybrid framework React Native, and use a few notification handler, such as local notification, remote notification using firebase, and third party marketing tools library.

I am fairly new to ios debugging, can someone help me identifying the crash source of attached log? Does it crash because it tries to open the app in the background? Or there are some network call from third party lib? Does the error happen in native obj c layer, or it already reached the javascript layer of React?The last line of thread 0 where the crash happened was: "dyld 0x1d4acedcc start + 2240m". From what I gathered, dyld itself is a dynamic framework linking process in runtime, does it mean it crash because it failed to link a framework?

Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-create watchdog transgression: app<com.bcad.blu.uat(EABDB60C-B43B-40F0-B9B8-EEA50D7818DA)>:1029 exhausted CPU time allowance of 9.52 seconds ProcessVisibility: Background ProcessState: Running WatchdogEvent: scene-create WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 14.150 (user 10.740, system 3.410), 38% CPU", "Elapsed application CPU time (seconds): 9.818, 27% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive>

Triggered by Thread: 0

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

crash-2024-03-04-212235.log

Boost

Answer 1

hadicrax OP

Mar ’24

Reuploaded log with .crash extension

crash-2024-03-04-212235.crash

0

Answer 2

DTS Engineer OP

Apple

Mar ’24

Consider this from your crash report:

Termination Reason: FRONTBOARD 2343432205

In hex that value is 0x8badf00d (‘ate bad food’), which means your app has been killed by the watchdog. See Addressing watchdog terminations.

Looking at the backtrace of the main thread I see this:

Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libsystem_kernel.dylib … mach_msg2_trap + 8
1   libsystem_kernel.dylib … mach_msg2_internal + 80
2   libsystem_kernel.dylib … mach_msg_overwrite + 436
3   libsystem_kernel.dylib … mach_msg + 24
4   CoreFoundation         … __CFRunLoopServiceMachPort + 160
5   CoreFoundation         … __CFRunLoopRun + 1208
6   CoreFoundation         … CFRunLoopRunSpecific + 608
7   Foundation             … -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
8   Foundation             … -[NSRunLoop(NSRunLoop) runUntilDate:] + 64
9   blu uat                … +[RNSplashScreen show] + 192
10  blu uat                … -[AppDelegate application:didFinishLaunchingWithOptions:] + 1076
11  UIKitCore              … -[UIApplication _handleDelegateCallbacksWithOptions:isSuspended:restoreState:] + 320
12  UIKitCore              … -[UIApplication _callInitializationDelegatesWithActions:forCanvas:payload:fromOriginatingProcess:] + 2856
…
47  dyld                   … start + 2240

Frame 47 through 11 are the standard app startup sequence. Frame 10 is your app’s -application:didFinishLaunchingWithOptions: callback, which is presenting some sort of splash screen in frame 9. I think this is where things go south. I see multiple problems here:

Presenting a splash screen is a bad idea in general on iOS.
This code seems to be presenting it synchronously, by recursively running the run loop. Recursively running the run loop to present UI isn’t supported on iOS [1] [2].
Presenting a splash screen when your app is launched in the background to handle a push notification is pointless. The user is not going to see it.

It’s hard to offer concrete advice here because this is all mixed up with your third-party tooling. My general advice is that you seek help from the support channel for that tooling.

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

[1] On macOS, AppKit does, under limited circumstances, support this.

[2] If you’re unfamiliar with run loops, you can ‘listen’ to be talk on them in WWDC 2010 Session 207 Run Loops Section.

0

Answer 3

hadicrax OP

Mar ’24

Hi @eskimo , thanks for the reply.

Yes, the issue was showing RNSplashScreen, when I disable it, it run without crash. For now I tacke it with an if-else condition to only show the splash screen when the source is not notification.

May I ask more, is it an expected behaviour that background notification calling app initialization (didFinishLaunchingWithOptions)? Or because some of our third party triggering didFinishLaunchingWithOptions from background notification? Because the crash happen on spesific OS, I guess in the previous OS the didFinishLaunchingWithOptions was not called by background notification?

0