The 0x8badf00d (“ate bad food”) exception code means that your app was killed by the watchdog for being insufficiently responsive. You can learn more about this in Technote 2151 Understanding and Analyzing iOS Application Crash Reports.
To debug this you should look at two items in the crash log:
The backtrace of the main thread
The Termination Description field
The backtrace of the main thread indicates that your app was blocked accessing the keychain when it was killed. It’s possible that this blocking is the cause of your problem, but I don’t think that’s the case here.
And that’s because of the Termination Description field, which looks like this (I’ve broken it up into multiple lines to make it easier to read):
Termination Description: SPRINGBOARD, scene-create watchdog transgression: com.XandJsoft.MyFamily exhausted real (wall clock) time allowance of 19.69 seconds | | ProcessVisibility: Foreground | ProcessState: Running | WatchdogEvent: scene-create | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 16.920 (user 16.920, system 0.000), 28% CPU", | "Elapsed application CPU time (seconds): 0.437, 1% CPU" | )
Line 4 indicates that your app was given (roughly) 20 seconds to launch. Now look at line 10, which indicates that your app spend roughly 17 seconds of that doing computation on the CPU. That’s a big chunk of time, and I’d argue it’s way too long for a couple of reasons:
It skirts very close to the watchdog limit of 20 seconds
You’re making the user wait way too long
My recommendation here is that you look at ways to optimise your launch time.
Share and Enjoy
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
Indeed, my applicationDidFinishLaunching method was a bit overloaded. It has been accepted now.
Thanks you for your help.
@eskimo, struggling almost the same thing, but the reason is really suprising for me:
Termination Description: SPRINGBOARD, scene-create watchdog transgression: com.app.id exhausted CPU time allowance of 2.97 seconds | ProcessVisibility: Background | ProcessState: Running | WatchdogEvent: scene-create | WatchdogVisibility: Background | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 15.300 (user 15.300, system 0.000), 62% CPU", | "Elapsed application CPU time (seconds): 5.126, 21% CPU" | ) Triggered by Thread: 0
exceeded 3 seconds of CPU consumption?
Having this in a very rare cases, when receiving voip push that laucnhes the app in background. And, according to logs, I have an infinite (DBL_MAX) amount of background time available, but the app is killed by the watchdog 3 seconds after applicationDidFinishLaunching.
What may be the reason of that short period of time available to the app before being killed by watchdog?
I would assume it's the pre-main time loading time, but according to our tests, this happens after a several laucnhes happened already, so the libraries should be cached already. My cold launch time is
Total pre-main time: 1.3 seconds (100.0%) dylib loading time: 1.0 seconds (73.8%) rebase/binding time: 34.72 milliseconds (2.5%) ObjC setup time: 45.06 milliseconds (3.3%) initializer time: 275.88 milliseconds (20.2%) slowest intializers : libSystem.B.dylib : 10.16 milliseconds (0.7%) SwinjectStoryboard : 207.26 milliseconds (15.2%)
While a warn launch is
Total pre-main time: 1.2 seconds (100.0%) dylib loading time: 991.26 milliseconds (79.3%) rebase/binding time: 29.23 milliseconds (2.3%) ObjC setup time: 38.92 milliseconds (3.1%) initializer time: 189.08 milliseconds (15.1%) slowest intializers : libSystem.B.dylib : 27.31 milliseconds (2.1%) SwinjectStoryboard : 104.84 milliseconds (8.3%)
But not that 15 seconds I see in the crash report.
I did some profiling and couldn't find anything heavy.
Is there any way I can workaround this? Happens rarely and always only in the background.