What does 8badf00d mean?

问题:

Sometimes my iPhone application crashes with a weird crashlog, that reads exception code is 0x8badf00d. The stacktraces show random snapshots of app execution, but nothing suspicious. This happens very rarely and I'm not able to find out how to reproduce it. Does anybody know more about this kind of exception and exception code?

Here is an excerpt from my crashlogs:

Exception Type: 00000020
Exception Codes: 0x8badf00d
Highlighted Thread: 0

Application Specific Information:
Failed to deactivate

Thread 0:
...
< nothing suspicious here >
...

Unknown thread crashed with unknown flavor: 5, state_count: 1

回答1:

0x8badf00d is the error code that the watchdog raises when an application takes too long to launch or terminate. See Apple's Crash Reporting for iPhone OS Applications document

回答2:

If you get Exception Type: 00000020 and Exception Codes: 0x8badf00d then it is watchdog timeout crash reports. The exception code 0x8badf00d is called "ate bad food".

The most common reason for this crash is synchronous activity on main thread. The fix is to switch to asynchronous activity on main thread.

Refer this Apple document for more detail.

回答3:

It is HexSpeak, see here: http://en.wikipedia.org/wiki/Hexspeak

回答4:

It's some programmer's idea of a joke. You have to pick a number for your code, but the number doesn't necessarily mean anything in itself. 8badf00d is just another way to write the number 2,343,432,205, and was chosen because it looks 'funny' when represented in hex for an exception log.

回答5:

It's a failure code added by a dev with a good sense of humor. Because hexadecimal uses letters as well as numbers, it's possible to come up with hex numbers that look approximately like english words, such as "0xdeadbeef", etc. I'm sure that the exception has a specific meaning, but if there's no major symptoms associated with it, you can probably ignore it without too much concern.

回答6:

0x8badf00d exception is raised by apple provided watchdog. The most common cause for watchdog timeout crashes in a network application is synchronous networking on the main thread. There are four contributing factors here:

synchronous networking — This is where you make a network request and block waiting for the response.

main thread — Synchronous networking is less than ideal in general, but it causes specific problems if you do it on the main thread. Remember that the main thread is responsible for running the user interface. If you block the main thread for any significant amount of time, the user interface becomes unacceptably unresponsive.

long timeouts — If the network just goes away (for example, the user is on a train which goes into a tunnel), any pending network request won't fail until some timeout has expired. Most network timeouts are measured in minutes, meaning that a blocked synchronous network request on the main thread can keep the user interface unresponsive for minutes at a time.

Trying to avoid this problem by reducing the network timeout is not a good idea. In some situations it can take many seconds for a network request to succeed, and if you always time out early then you'll never make any progress at all.

watchdog — In order to keep the user interface responsive, iOS includes a watchdog mechanism. If your application fails to respond to certain user interface events (launch, suspend, resume, terminate) in time, the watchdog will kill your application and generate a watchdog timeout crash report. The amount of time the watchdog gives you is not formally documented, but it's always less than a network timeout.

There are two common solutions:

asynchronous networking — The best solution to this problem is to run your networking code asynchronously. Asynchronous networking code has a number of advantages, not least of which is that it lets you access the network safely without having to worry about threads.

synchronous networking on a secondary thread — If it's prohibitively difficult to run your networking code asynchronously (perhaps you're working with a large portable code base that assumes synchronous networking), you can avoid the watchdog by running your synchronous code on a secondary thread.

Refer apple docs for more information.

回答7:

from wikipedia 0xBAADF00D ("bad food") is used by Microsoft's LocalAlloc(LMEM_FIXED) to indicate uninitialised allocated heap memory when the debug heap is used.[7]