So I'm working on a project in Visual C and I find a bug somewhere and attempt to trace it.

Once I locate where the problem is I notice in the debug watch window one of my pointers has been overwritten with 0xbaadf00d.

Bad Food?


I know I did not use this value anywhere in the project yet here it is. Coincidence? Practical Joke from Microsoft? What's going on?
Posted on 2003-05-05 18:52:49 by iblis
Weird one, I checked MS and it actually comes up on searches. They actually name the XP boot prefetch NTOSBOOT-B00DFAAD.PF. Some kind of bad joke I guess. MS says it means unitialized data ?

http://msdn.microsoft.com/msdnmag/issues/01/12/XPKernel/default.aspx
Posted on 2003-05-05 19:03:53 by donkey
Well that makes a little more sense now, but the problem wasn't uninitialized data, it was initialized data getting mysteriously overwritten. It's fixed now.

Too bad J and K aren't hex units.
"Dear Microsoft, 0xBAADJ0KE. Yours truly, iblis." ;)
Posted on 2003-05-05 19:17:54 by iblis
http://www.decafbad.com/twiki/sbin/view/Main/HexOddities :grin:

0xBADC0DE

0xBADBABE

...

:grin:

iblis,

0xBAADJ0KE make that BAD601CE ... 1C == K, 6 like G == J
Posted on 2003-05-05 19:56:24 by arkane
0xABADD00D :grin: Motorola = 2880294925, Intel = 231779755
Posted on 2003-05-05 20:35:45 by donkey
Well that makes a little more sense now, but the problem wasn't uninitialized data, it was initialized data getting mysteriously overwritten. It's fixed now.
Yeah, so was it your fault, or was it something that MS were doing? Did the problem occur between keyboard and chair? :grin:
Posted on 2003-05-05 21:13:43 by sluggy
I have no idea what it was. I ended up taking a different approach on the problem so I just deleted the errant code altogether.

In this particular program different threads pass messages back and forth to eachother. Somewhere between thread1 posting a message and thread2 retrieving the message, the data got overwritten with that value.
Posted on 2003-05-05 22:32:38 by iblis
It has most likely been a problem in your code - some of those problems are all but logical though. Threading can be a real hellish thing to debug :).

I rather like the various fill values VC uses in debug builds - many times, I have caught errors I would not have caught if the values had been zero-filled (though of course some pointer errors are more easily caught with zero-filling). Also, "buffer security check" (etc) in vs.net can be rather nice in debug builds. I don't like leaving them on in release, though.
Posted on 2003-05-06 02:11:33 by f0dder
0x1337 :grin:
Posted on 2003-05-06 09:22:52 by bazik
Yeah it most likely was a problem on my end.
But seeing a value change from a memory address to 0xbaadf00d was creepy.
Posted on 2003-05-06 11:14:15 by iblis
I can imagine ;)

since you're doing C coding, get hold of a memory debugger library - like paul nettle's (http://www.fluidstudios.com/publications.html) - can make life a lot easier.
Posted on 2003-05-06 11:17:16 by f0dder
f0dder thanks. There are some nice little tools there. Unfortunately that mem tester looks like it only works with the standard C memory functions. Since this time I'm writing for Win32 only, I'm using straight Win32 API.

I have a program around here somewhere that hooks the Windows memory APIs of your program and generates a log file. I should dig it out.
Posted on 2003-05-06 11:31:51 by iblis