Thread: Crash in Debugger

Originally Posted by Bubba

According to my experience the only variables intialized to zero in release are those specifically assigned a value of zero by the programmer. In other words I don't think that the assembly that MSVC spits out in any way auto-inits anything to zero. I remember back in the day that Borland and possibly DJGPP did do this which made debugging uninitialized variable/memory errors extremely difficult. Again I'm not sure if Borland and DJGPP only did this in release or in debug since I didn't even understand the concept of release and debug back then.

This is correct of course, but the reason things end up "mostly" zero is simply because most memory is zero. The OS itself clears memory pages to zero when they are committed into a process's address space. It's not the program that does it, it's the OS itself.

(If the OS didn't do that, then a program could get data from other extinct processes by just malloc'ing a big block of memory and looking at it -- that's obviously an unacceptable security problem)

Originally Posted by IceDane

As far as I can see, and have seen, when writing apps for windows using Visual Studio with debug config, all vars are filled with 0xCC, not 0xcd, but obviously, that is an irrelevant detail.

There was a time when 0xCDCD was the default although IIRC isn't there a setting somewhere in VS where you can set what the default value is? Been so long I cannot remember...

Originally Posted by jeffcobb

There was a time when 0xCDCD was the default although IIRC isn't there a setting somewhere in VS where you can set what the default value is? Been so long I cannot remember...

I think you can probably configure it. In any case, you can always override the global new operator to fill dynamic memory with anything you want, really.

In our software testing, we enable floating-point exceptions so that FP divides by zero or other bad things will cause a crash that we can track. Once, we had a very rare crash due to an invalid IEEE bit pattern that was very hard to track down. We knew it was uninitialized memory, but it was difficult to figure out where, because most of the time, although the value was uninitialized, it represented some valid number and everything worked okay. A developer around here had the bright idea to fill all dynamic memory with the value 0x7fc00001, which represents an invalid 32-bit IEEE float value. We INSTANTLY found the problem.