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.

Bustard

0x41b80d6d is also a bad (unaligned) address. – Waddle

Is the stack corrupted? – Twirl

@MooingDuck Possibly. My question is specifically about the 0xfbad8001 address, which seems to be too big of a coincidence – Bustard

@DigitalTrauma: If the stack is corrupted, and that value is not a valid pointer, it stands to reason that that value is not a pointer at all. It could be anything else (or a combination of things) on the stsack. See https://mcmap.net/q/539383/-what-is-undefined-behavior – Twirl

@close-voter Perhaps I'm mis-interpreting help-center scope, but how is "program I am debugging in GDB" not about programming? – Bustard

@MooingDuck If I google search for "0xfbad8001", then there are lot of hits showing this address in backtraces. So this particular value seems to have some significance, which is what I am trying determine with this question. But perhaps it is just a coincidental value on the stack, as you say. – Bustard

@DigitalTrauma: I have also observed it's appearance in various (seemingly unrelated) backtraces, though I have no better explanation than "chance" thus far. You've piqued my interest though. Actually, most of the code has to do with networking, could it be a proprietary error code on some network device? – Twirl

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.

Glomerulus

+1 Useful advice, but I'm looking for more detail of where this actually comes from. I just put a bounty on it if you're interested :) – Bustard

There is not enough info to reproduce and diagnose your specific situation. You could conduct full text searches of various parts of the Linux kernel and GCC or you could get lucky and find the guy who wrote it. Best of luck. – Glomerulus

Awarding you the bounty, but not accepting your answer ;-) I still don't have a complete answer to the question, but I do appreciate the advice, and hate to see the bounty points disappear. – Bustard

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.

Desinence