Yes -- In debug mode, uninitialized memory is usually filled with a bit pattern that helps to shake out these kinds of bugs -- on Windows, debug uninit memory is filled with 0xCD repeated over and over. In release, the memory will probably just contain zeros. Since most variables are, or should have been, initialized to zero, this can hide the uninitialized memory bug.Originally Posted by jeffcobb
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
l am trying to remember which system/OS filled memory with 0xDEADBEEF ... in any event I remember a single uninitialized var on Win31 causing us grief b/c if randomly initialized itself to zero on some machines (and this was a proper value as per the application) and some random non-zero number on others causing mayhem. Of course, the machines that it initialized to zero on were all dev boxen and the machine it went nuts on were the clients, 50 miles away...in the dead of winter....brrr! That lesson alone as re-inforced the "init your vars" rule in my mind ever since....even if the vars are not yours (worked on a team) there was never a case where it was "right" not to init....
<rant mode off...I now return you to your bug...>
Peace
Jeff
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.
"What's up, Doc?"
"'Up' is a relative concept. It has no intrinsic value."
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.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
