3

In my ios app, I start listening user's location updates in the background for a while (up to 15 mins) when I receive background fetch execution. However, after I stop updates, the app crashes with the 0x8badf00d error.

I've enabled background location and background fetch permissions, and I also have enabled background location updates on CLLocationManager.

Any idea on why this error happens?

Esref
  • 336
  • 1
  • 7
  • 18
Hüsnü Şener
  • 51
  • 4
  • 2
    Are you consuming a network service? If so you need to make async. It is blocking the app and it cannot change the state, thus the crash. – Rogers Sampaio Oct 09 '17 at 21:21
  • Have you tried restarting it? – epokhe Oct 09 '17 at 21:27
  • @RogersSampaio I use AZSClient (Azure Storage Client) for transferring some information to the blob server. From my point, it handles the job in async way; but I don't know it's internals. I'll check for it. – Hüsnü Şener Oct 09 '17 at 21:36

1 Answers1

1

The problem isn’t that it isn’t running in the background, but rather whatever was running was blocking the main thread.

The 0x8badf00d (“ate bad food”; lol) indicates that the watchdog process (that monitors for dead/blocked processes) killed your app, generally because you did something to block the main thread. If you avoid blocking the main thread, this error should go away. See Technical Note 2151: Understanding and Analyzing Application Crash Reports and search for 0x8badf00d.

As it says:

The exception code 0x8badf00d indicates that an application has been terminated by iOS because a watchdog timeout occurred. The application took too long to launch, terminate, or respond to system events. One common cause of this is doing synchronous networking on the main thread. Whatever operation is on Thread 0 needs to be moved to a background thread, or processed differently, so that it does not block the main thread.

They’re focusing on synchronous network requests, but it can be anything that blocked the main thread for too long, whether a slow synchronous process or a deadlock or whatever. You should look at the stack trace for thread 0 and see if you can identify what blocked the main thread. There’s not enough here for us to diagnose it, though.

Common culprits include synchronous network calls, synchronous GCD calls, inappropriate use of semaphores, locks, or dispatch group “wait” calls, deadlocks, etc.

Rob
  • 415,655
  • 72
  • 787
  • 1,044