I have a very old program, that crashed. While debugging the crash with Windbg, that I've installed as the post-mortem debugger, I noticed that one of the registers was set to a strange value:
rdx=00000000deadface
Stack trace of the thread that caused the crash (access violation) contained some suspicious value as well:
objc_1!objc_msg_lookup+0x29:
00000000 6784a4c5 488b4a38 mov rcx,qword ptr [rdx+38h] ds:00000000deadfb06=????????????????
I've obtained the first value from register listings that was included in the output of the !analyze -v command. The second was produced by the command to list stack of the failing thread (~9k).
Is Windbg trying to tell me something by putting such values into registry and stack dumps, or am I just a victim of some old test code or a hoax (or is it just a coincidential value)?
The program is written in obj-c and runs an old versions of GNUstep and obj-c runtime.
It turned out it is the GNUstep way to tell that the program tried to send a message (=invoke a method) on an object that was already deallocated.
If an object is deallocated, GNUstep sets 0xdeadface as a value of the object's isa pointer. isa pointer referes to the class the object is an instance of; objective-c runtime uses this pointer to resolve object's methods when dispatching messages to it.
Therefore, every attempt to send a message to a deallocated object results in a segfault, that, if trapped in a debugger, usually shows 0xdeadface in a register or on stack.