0xfbad8001 The magic number in the opposite direction

Question

I am considering the following reverse line of a program that 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 am interested in the frame address 0xfbad8001 and what it means.

The platform is x86-based, so this invalid address is not valid. Given that the "bad" is encoded in a hexadecimal value, I assume it is a magic number, but so far I have not been able to determine who sets this value or why. I tried searching on google and the LXR online databases for the kernel and glibc, but did not find any lines of code that really set this value.

If I search google for "fbad8001", then there are many hits showing this address in backtraces and memory dumps. This means that this value has a certain meaning, and I assume that this is a magic number from somewhere, but so far I have not been able to find the code that installs it.

Who sets this value and what does it mean?

The kernel is based on Linux 3.4.10 and glibc is 2.15.

---

Like the kernel and the glibc source, I also grepped through the gcc, gdb and binutils source, but still do not see smoking guns. I'm not sure where else to look.

Answer 1

My interpretation is that it is a fill value that has never been seen, and was informally selected by one or more (unspecified) system programmers in accordance with a specific (undefined) purpose.

Please note that the address above does not matter either. This suggests that everything you read from the stack from there is suspicious.

I agree that fbad8001 is likely to be the selected value, but not a big deal. If you want to continue exploring, you need to use a suitable debugging tool to directly check the stack. You should be able to find valid stack frames through validation (if any), and you can find several instances of this value (or other similar illegal values) populating parts of the stack that are not intended to be reached.

If this is a debug assembly, you can find strips of values ​​such as sentries between stack frames. If the previous frame stack is broken, this value can be far down. You will not know until you look.

If you can find out what is responsible for a particular region of the stack, you will know better who asks why this value appears there. I assume that you will learn a lot and achieve little by following this path.

Answer 2

I came across your question recently when I was debugging a crash when the same suspicious constant 0xFBAD8001 occurred.

In my case, there was a local variable that was used long before the function remained. It was then rewritten by the printf () function stack frame, and when the pointer was used again, the structure contained the value 0xFBAD8001.

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