ITunes Connect - Crash report - Code 0x8badf00d

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.

Hi eskimo,

Sorry i don't know how to use this forum i am new here. I tried to send post but i couldn't find how to send post. I just saw here Reply button and that's why im writing here. I uploaded my first game app to review and review result is rejected. They sent me crash logs but i didn't understand anything. Is it possible to explain me what is the issue here? It works on my device and all of simulator devices.

Guideline 2.1 - Performance - App Completeness

Your app continued to crash on iPad running iOS 12.2 on WiFi when we were playing the game.

Date/Time: 2019-03-28 03:51:34.1797 +0900

Launch Time: 2019-03-28 03:51:25.7709 +0900

OS Version: iPhone OS 12.2 (16E227)

Baseband Version: 7.55.01

Report Version: 104

Exception Type: EXC_BREAKPOINT (SIGTRAP)

Exception Codes: 0x0000000000000001, 0x00000001010f0a4c

Termination Signal: Trace/BPT trap: 5

Termination Reason: Namespace SIGNAL, Code 0x5

Terminating Process: exc handler [1752]

Triggered by Thread: 0

Thread 0 name: Dispatch queue: com.apple.main-thread

Thread 0 Crashed:

0 Save The Princess 0x00000001010f0a4c 0x1010e8000 + 35404

1 Save The Princess 0x00000001010f0a7c 0x1010e8000 + 35452

2 PhysicsKit 0x00000001f8159e48 0x1f8145000 + 85576

3 PhysicsKit 0x00000001f8157e64 0x1f8145000 + 77412

4 SpriteKit 0x00000002046c7a48 0x20468d000 + 240200

5 SpriteKit 0x00000002046ec114 0x20468d000 + 389396

6 SpriteKit 0x00000002046e77f4 0x20468d000 + 370676

7 SpriteKit 0x00000002046e6bf8 0x20468d000 + 367608

8 SpriteKit 0x00000002046e9c54 0x20468d000 + 379988

9 SpriteKit 0x000000020472cc18 0x20468d000 + 654360

10 QuartzCore 0x00000001f1f21194 0x1f1f10000 + 70036

11 IOKit 0x00000001ede1b718 0x1ede16000 + 22296

12 CoreFoundation 0x00000001edb2ad30 0x1edaa7000 + 539952

13 CoreFoundation 0x00000001edb51934 0x1edaa7000 + 698676

14 CoreFoundation 0x00000001edb51080 0x1edaa7000 + 696448

15 CoreFoundation 0x00000001edb4bea4 0x1edaa7000 + 675492

16 CoreFoundation 0x00000001edb4b354 0x1edaa7000 + 672596

17 GraphicsServices 0x00000001efd4b79c 0x1efd41000 + 42908

18 UIKitCore 0x0000000219d0cb68 0x219452000 + 9153384

19 Save The Princess 0x00000001010f10c0 0x1010e8000 + 37056

20 libdyld.dylib 0x00000001ed6118e0 0x1ed610000 + 6368

Thread 1:

0 libsystem_pthread.dylib 0x00000001ed7e2cd0 0x1ed7d4000 + 60624

Thread 2:

0 libsystem_pthread.dylib 0x00000001ed7e2cd0 0x1ed7d4000 + 60624

Thread 3:

0 libsystem_pthread.dylib 0x00000001ed7e2cd0 0x1ed7d4000 + 60624

Thread 4 name: com.apple.uikit.eventfetch-thread

Thread 4:

0 libsystem_kernel.dylib 0x00000001ed7520f4 0x1ed73a000 + 98548

1 libsystem_kernel.dylib 0x00000001ed7515a0 0x1ed73a000 + 95648

2 CoreFoundation 0x00000001edb50cb4 0x1edaa7000 + 695476

3 CoreFoundation 0x00000001edb4bbc4 0x1edaa7000 + 674756

4 CoreFoundation 0x00000001edb4b354 0x1edaa7000 + 672596

5 Foundation 0x00000001ee518fcc 0x1ee511000 + 32716

6 Foundation 0x00000001ee518e5c 0x1ee511000 + 32348

7 UIKitCore 0x0000000219df2540 0x219452000 + 10093888

8 Foundation 0x00000001ee6456e4 0x1ee511000 + 1263332

9 libsystem_pthread.dylib 0x00000001ed7df2c0 0x1ed7d4000 + 45760

10 libsystem_pthread.dylib 0x00000001ed7df220 0x1ed7d4000 + 45600

11 libsystem_pthread.dylib 0x00000001ed7e2cdc 0x1ed7d4000 + 60636

Thread 5 name: JavaScriptCore bmalloc scavenger

Thread 5:

0 libsystem_kernel.dylib 0x00000001ed75cee4 0x1ed73a000 + 143076

1 libsystem_pthread.dylib 0x00000001ed7d7cf8 0x1ed7d4000 + 15608

2 libc++.1.dylib 0x00000001ecd34090 0x1ecd2c000 + 32912

3 JavaScriptCore 0x00000001f4d21238 0x1f4c97000 + 565816

4 JavaScriptCore 0x00000001f4d2522c 0x1f4c97000 + 582188

5 JavaScriptCore 0x00000001f4d249a4 0x1f4c97000 + 580004

6 JavaScriptCore 0x00000001f4d263e4 0x1f4c97000 + 586724

7 libsystem_pthread.dylib 0x00000001ed7df2c0 0x1ed7d4000 + 45760

8 libsystem_pthread.dylib 0x00000001ed7df220 0x1ed7d4000 + 45600

9 libsystem_pthread.dylib 0x00000001ed7e2cdc 0x1ed7d4000 + 60636

Thread 6 name: WebThread

Thread 6:

0 libsystem_kernel.dylib 0x00000001ed7520f4 0x1ed73a000 + 98548

1 libsystem_kernel.dylib 0x00000001ed7515a0 0x1ed73a000 + 95648

2 CoreFoundation 0x00000001edb50cb4 0x1edaa7000 + 695476

3 CoreFoundation 0x00000001edb4bbc4 0x1edaa7000 + 674756

4 CoreFoundation 0x00000001edb4b354 0x1edaa7000 + 672596

5 WebCore 0x00000001f67a5480 0x1f63dc000 + 3970176

6 libsystem_pthread.dylib 0x00000001ed7df2c0 0x1ed7d4000 + 45760

7 libsystem_pthread.dylib 0x00000001ed7df220 0x1ed7d4000 + 45600

8 libsystem_pthread.dylib 0x00000001ed7e2cdc 0x1ed7d4000 + 60636

I didn't copy all logs because it's very long. I hope it's enough.

Thank you in advance

I tried to send post but i couldn't find how to send post.

OK, let’s fix that problem first. To start a new thread for your question:

1. Go to the Xcode > Debugger topic area.

2. On the right, near the top, there’s a link entitle Start a discussion. Click that.

3. From there it should be obvious.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

i have the same question with voip

do you resolve

Hi,

We have a similar problem with our app when responding to an iBeacon region launch. In some cases, the watchdog gives us 2.6 seconds to create the scene in background, which our (fairly large) app simply can't achieve. Weirdly, after the first launch attempt fails/crashes (bad food), iOS almost immediately launches our app again with a larger allowance and starts up successfully.

@eskimo Any idea? I think it's weird that the app at first has a low allowance, and then immediately launches again with a larger allowance.

(iOS 13.3, iPhone 7 with a poor battery)

I think it's weird that the app at first has a low allowance, and then immediately launches again with a larger allowance.

Yeah, that is a little weird, but it kinda makes sense when you think about it. The allowance for resuming an app is much lower than the allowance for launching it, and thus if your app crashes it gets the launch allowance the next time around. I guess the alternative would be for the system to stop launching your app, which is probably not what you want, eh? (-:

The obvious fix here is to optimise your scene creation. Two seconds should be more than enough to (effectively) bring up a window. If necessary you can run some of the required work asynchronously, using a

UIApplication

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

@eskimo

Thanks for your quick response!

I understand that resuming the app requires less time (and thus a lower allowance) than launching the app. However, what I meant is that the first allowance (2.6 seconds) was for a (background) launch (`scene-create`) and not for resuming the app. After that first attempted launch crashed, it was almost immediately launched again with a higher allowance.

> Two seconds should be more than enough to (effectively) bring up a window.

What exactly is involved in bringing up the window?

Is it:

• Returning from `didFinishLaunchingWithOptions`?
• Having instantiated the `UIWindow` and making it key and visible?
• Completing the first layout update?

And when does the watchdog timer start ticking? Is that before or after the libraries are loaded?

We are facing the same issue on App launch in iPhone 7( iOS 13.3). OS time allowance is 2.23 seconds.

Termination Description: SPRINGBOARD, scene-create watchdog transgression: application:433 exhausted CPU time allowance of 2.23 seconds

@eskimo any update on above question?