Magic debug values
Magic debug values are specific values written to memory during allocation or deallocation, so that it will later be possible to tell whether or not they have become corrupted, and to make it obvious when values taken from uninitialized memory are being used. Memory is usually viewed in hexadecimal, so memorable repeating or hexspeak values are common. Numerically odd values may be preferred so that processors without byte addressing will fault when attempting to use them as pointers (which must fall at even addresses). Similarly, they may be chosen so that they are not valid codes in the instruction set for the given architecture.
Since it is very unlikely, although possible, that a 32-bit integer would take this specific value, the appearance of such a number in a debugger or memory dump most likely indicates an error such as a buffer overflow or an uninitialized variable.
Famous and common examples include:
Magic debug values
| Code |
Description |
..FACADE |
Used by a number of RTOSes |
8BADF00D |
Used by Apple as the exception code in iPhone crash reports when an application has taken too long to launch or terminate. |
A5A5A5A5 |
Used in embedded development because the alternating bit pattern (10100101) creates an easily recognized pattern on oscilloscopes and logic analyzers. |
ABABABAB |
Used by Microsoft's HeapAlloc() to mark "no man's land" guard bytes after allocated heap memory |
ABADBABE |
Used by Apple as the "Boot Zero Block" magic number |
ABADCAFE |
A startup to this value to initialize all free memory to catch errant pointers[clarification needed] |
BAADF00D |
Used by Microsoft's LocalAlloc(LMEM_FIXED) to mark uninitialised allocated heap memory |
BADBADBADBAD |
Burroughs large systems "uninitialized" memory (48-bit words) |
BADC0FFEE0DDF00D |
Used on IBM RS/6000 64-bit systems to indicate uninitialized CPU registers |
BADCAB1E |
Error Code returned to the Microsoft eVC debugger when connection is severed to the debugger |
BADDCAFE |
On Sun Microsystems' Solaris, marks uninitialised kernel memory (KMEM_UNINITIALIZED_PATTERN) |
BEEFCACE |
Used by Microsoft .NET as a magic number in resource files |
C0DEDBAD |
A memory leak tracking tool which it will change the MMU tables so that all references to address zero |
CAFEBABE |
Used by both Universal Mach-O binaries and Java .class files |
CAFEFEED |
Used by Sun Microsystems' Solaris debugging kernel to mark kmemfree() memory |
CCCCCCCC |
Used by Microsoft's C++ debugging runtime library to mark uninitialised stack memory |
CDCDCDCD |
Used by Microsoft's C++ debugging runtime library to mark uninitialised heap memory |
CEFAEDFE |
Seen in Intel Mach-O binaries on Apple Inc.'s Mac OS X platform (see FEEDFACE) |
DDDDDDDD |
Used by MicroQuill's SmartHeap and Microsoft's C++ debugging heap to mark freed heap memory |
DEADBABE |
Used at the start of Silicon Graphics' IRIX arena files |
DEADBEEF |
Famously used on IBM systems such as the RS/6000, also used in the original Mac OS operating systems, OPENSTEP Enterprise, and the Commodore Amiga. On Sun Microsystems' Solaris, marks freed kernel memory (KMEM_FREE_PATTERN) |
DEADDEAD |
A Microsoft Windows STOP Error code used when the user manually initiates the crash. |
DEADF00D |
Used by Mungwall on the Commodore Amiga to mark allocated but uninitialised memory [12] |
DEADFA11 |
Used by Apple as the exception code in iPhone crash reports when the user has force-quit the application. |
EBEBEBEB |
From MicroQuill's SmartHeap |
FADEDEAD |
Comes at the end to identify every AppleScript script |
FDFDFDFD |
Used by Microsoft's C++ debugging heap to mark "no man's land" guard bytes before and after allocated heap memory |
FEE1DEAD |
Used by Linux reboot() syscall |
FEEDFACE |
Seen in PowerPC Mach-O binaries on Apple Inc.'s Mac OS X platform. On Sun Microsystems' Solaris, marks the red zone (KMEM_REDZONE_PATTERN) |
FEEEFEEE |
Used by Microsoft's HeapFree() to mark freed heap memory |
Note that most of these are each 32 bits long — the dword size of 32-bit architecture computers.
The prevalence of these values in Microsoft technology is no coincidence; they are discussed in detail in Steve Maguire's book Writing Solid Code from Microsoft Press. He gives a variety of criteria for these values, such as:
- They should not be useful; that is, most algorithms that operate on them should be expected to do something unusual. Numbers like zero don't fit this criterion.
- They should be easily recognized by the programmer as invalid values in the debugger.
- On machines that don't have byte alignment, they should be odd numbers, so that dereferencing them as addresses causes an exception.
- They should cause an exception, or perhaps even a debugger break, if executed as code.
Since they were often used to mark areas of memory that were essentially empty, some of these terms came to be used in phrases meaning "gone, aborted, flushed from memory"; e.g. "Your program is DEADBEEF".
Pietr Brandehörst's ZUG programming language initialized memory to either 0000, DEAD or FFFF in development environment and to 0000 in the live environment, on the basis that uninitialised variables should be encouraged to misbehave under development to trap them, but encouraged to behave in a live environment to reduce errors[citation needed].
