0xfbad8001 Magic Number in backtrace

Question

I am looking at the following backtrace of a program I am debugging in GDB:

Thread 7 (Thread 3983):
#0  0xf7737430 in __kernel_vsyscall ()
#1  0x41b85412 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:142
#2  0x41b80d6d in _L_lock_686 () from libpthread.so.0
#3  0xfbad8001 in ?? ()
#4  0x080eac80 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

In particular I'm interested in the frame address of 0xfbad8001 and what it means.

The platform is x86 based, so this unaligned address is invalid. Given "bad" is encoded into the hex value, I'm guessing this is a magic number, but so far I haven't been able to determine who sets this value or why. I have tried to search google and online LXR databases for the kernel and glibc, but haven't found any lines of code that would actually set this value.

If I google search for "fbad8001", then there are lot of hits showing this address in backtraces and memory dumps. So this particular value seems to have some significance, and I am assuming it is a magic number from somewhere, but so far I haven't been able to find the code that sets it.

Who sets this value, and what does it mean?

The kernel is Linux 3.4.10 based and glibc is 2.15.

---

As well as kernel and glibc source, I have also grepped through gcc, gdb and binutils source, but still don't see any smoking guns. I'm not sure where else to look.

Answer 1

My interpretation of this is that it's a fill value intended never to be seen, and chosen informally by one or more (unspecified) systems programmers to suit a particular (unspecified) purpose.

Please note that the address above is unaligned too. This suggests that everything you read off the stack from there down is suspect.

I agree that fbad8001 is likely to be a chosen value, but not one of great significance. If you want to investigate further you need to use a suitable debugging tool to inspect the stack directly. You should be able to find valid stack frames by inspection (if there are any), and you may well find a number of instances of this value (or other similar illegal values) filling parts of the stack not intended to be reached.

If this is a debug build, you may find bands of such values as sentinels between stack frames. If the previous stack frame is broken this value may be a long way down. You won't know until you look.

If you can find out what is responsible for that particular region of the stack you will know better who to ask as to why that value appears there. My guess is you will learn much and achieve little by following this path.

Answer 2

I stumbled upon your question recently, when I was debugging a crash where the very same suspicious constant 0xFBAD8001 occurred.

In my case there was a local variable that got used long after its function scope was left. It was then rewritten by a printf() function's stack frame and when the pointer got used again, the structure contained the value of 0xFBAD8001.

The magic constant comes from glibc, where it's used for flags by libio's _IO_FILE structure.
The high order half contains the magic 0xFBAD8000 value, the rest is used for flags.
That's why it was so hard to google it.