Geek Answers Handbook

What are the common values ​​for uninitialized memory for debugging?

Once upon a time, I found out about filling up unused / uninitialized 0xDEADBEEF memory, so that in the debugger or crash report, if I ever saw this value, I know I'm looking at uninitialized memory. I saw from the 0xBBADBEEF report iOS uses 0xBBADBEEF .

What other creative values ​​are used by people? Are there any specific benefits to any particular benefits?

The most obvious advantage of values ​​that turn into words is that, at least for most people, if the words are in their language, they easily go out where, as soon as a strict numerical value is less likely to stick out.

But maybe there is another reason for choosing numbers? For example, an odd number can lead to a processor failure (68000), for example, with certain memory accesses, so it is better to select 0x0BADBEEF through 0xBADBEEF0 . Are they any other values ​​(possibly specific processors) that have a specific advantage for use in uninitialized memory?

+6
source share
2 answers

Generally speaking, you need a value that is unlikely to happen to “work” when interpreted as a whole, pointer, or string. So here are a few limitations:

  • Do not use a value that is a multiple of the smallest “normal” alignment in your target architecture. For x86, this is 4 (bytes), so there are no values ​​that are divisible by 4. This ensures that if the value is interpreted as a pointer, it will be clearly incorrect. If you use architecture other than x86, you can even use a value that will lead to an alignment trap if it is used as a pointer.

  • Do not use a value that can be a reasonably small (positive or negative) integer. Your typical "int" variable in a C program will never be more than 1000 or so, so don't use small digits as filling in your empty data.

  • Do not use a value consisting entirely of valid ASCII characters. Make sure there is at least one byte with a high set of bits. These days you need to make sure that they are not valid UTF-8 values, or possibly UTF-16.

  • You have no null bytes in the value. Too many cases where it would be “useful” to prevent program crashes - line termination, giving a non-int field a reasonable value, etc.

  • Do not use single (or two) byte values ​​that repeat over and over. Having a full-word-length pattern can make it easier to determine how your wild pointer got where it is, at least narrowing down what operations move it from the beginning of the pattern.

  • Do not use a value that maps to a valid address for a "typical" process. If the most significant bits are set, it usually takes a lot of malloc () before your process gets large enough to make a valid address.

Perhaps unsurprisingly, patterns like 0xDEADBEEF meet all of these requirements.

+7
source

One of the technical terms for such values ​​is the “venom value”.

The hexadecimal numbers that form English words are called Hexspeak. The Hexspeak Wikipedia article largely answers this question by cataloging many well-known constants used for different things, including several that are used as indicators of poison / canary / sanity checks, as well as other uses, such as error codes or addresses IPv6.

I seem to recall some change to 0xBADF00D . (possibly with a duplicate letter, as your second example).

There is also 0xDEADC0DE . (Googling for where I saw this found the Wikipedia article linked above).

Other English words in hexadecimal I saw: Java .class files use 0xCAFEBABE as a magic number (first 4 bytes of the file). As a game on this, I think the Jikes JVM uses 0xDEADBABE as a health check constant.

Apparently, Java was not the first user of 0xCAFEBABE . Wikipedia says: “ It was originally created by NeXTSTEP developers as a reference to barists on Peet Coffee and Tea ” and was used by people who developed Java before they thought of the name “Java”. Thus, he did not come out of Java → coffee (if something is the other way around), it is just an old non-feminist technical culture .: (

re: update: Choosing a good value . For the poison value (not the error code), you want all the bytes to be different, not 0x00 or 0xFF , as these are probably the most likely values ​​for the erroneous single-byte storage. This is especially important for things like the canary stack (for detecting buffer overflows), or in other cases where it is important to note that it is not overwritten.

Your assumptions about choosing an odd value make a lot of sense. The wrong memory address in the virtual memory layout of typical processes is a big advantage . Failure as early as possible is optimal for debugging. Anyway, this probably means having a set of high bits is a good idea, so 0x0... is probably not a good idea.

+5
source

More articles:


All Articles