I often notice that when I allocate a chuck of memory it will be zero-ed out in debug mode. But in release mode, those memory chunks are just set to random stuff.
Is there any setting in Visual studio that forces memory to be filled with a specific pattern or something, in debug mode? Tracking down uninitialized memory problems are alot harder in debug mode when everything gets initially zeroed out.
initializing variables in debug mode
This is kind of like the opposite to why debug mode zeros out memory. Are you saying you prefer uninitialised memory to be random?
Debug mode zeros out newly allocated memory to try to help you track down bugs, with quite a lot of overhead actually. Release mode just lets you do whatever the hell you want with whatever was left over in that memory from previous operations.
Generally we tend to avoid these issues with higher level constructs (smart pointers etc) than having control of the bit pattern than memory contains if not fully allocated and constructed.
Debug mode zeros out newly allocated memory to try to help you track down bugs, with quite a lot of overhead actually. Release mode just lets you do whatever the hell you want with whatever was left over in that memory from previous operations.
Generally we tend to avoid these issues with higher level constructs (smart pointers etc) than having control of the bit pattern than memory contains if not fully allocated and constructed.
Author
Are you saying you prefer uninitialised memory to be random?
Yup
For example, a problem I just had was that I was malloc-ing a chuck a memory, and reading it back as a int variable. In debug mode, that int is zero, but in release mode, its some random value which sometimes crashes my app.
If that memory was initially filled with junk in debug mode, I think it'd be alot easier to track that bug down, because in debug mode, I can step through the code, view stack traces, etc...which I can't do in release mode.
(Of course I try not to use uninitialized memory....but sometimes I make mistakes....)
I'm surprised that you are seeing it initialized to zeros.
Memory trackers will often fill it with a specific variable. Common values include : 0xcdcdcdcd 0xdeadbeaf 0xdeadface ... and many more.
Microsoft's CRT debug heap uses: 0xCC, 0xCD, 0xDD, 0xFD, 0xAB, 0xBAADF00D.
The CC and CD values are uninitialized (different allocation methods), DD and BAADF00D values have been freed (via alternate methods), FD and AB are out-of-bounds memory for overrun detection.
You are correct that in release builds it is preferable to see random. In debug builds, I would rather see something that causes invalid data to break the game. The value of '0' is often perfectly acceptable for defaults. It provides blank strings and a reasonably sane digit for numeric processing. The C function strlen() says a zero string is empty, but will crash on a CDCDCD buffer after it passes the end of your allocation. When a number defaults to '0' you don't think twice, but when you see '3452816845" you notice.
If you are seeing them initialized to zero that would mean something other than the debug heap is setting it.
Memory trackers will often fill it with a specific variable. Common values include : 0xcdcdcdcd 0xdeadbeaf 0xdeadface ... and many more.
Microsoft's CRT debug heap uses: 0xCC, 0xCD, 0xDD, 0xFD, 0xAB, 0xBAADF00D.
The CC and CD values are uninitialized (different allocation methods), DD and BAADF00D values have been freed (via alternate methods), FD and AB are out-of-bounds memory for overrun detection.
You are correct that in release builds it is preferable to see random. In debug builds, I would rather see something that causes invalid data to break the game. The value of '0' is often perfectly acceptable for defaults. It provides blank strings and a reasonably sane digit for numeric processing. The C function strlen() says a zero string is empty, but will crash on a CDCDCD buffer after it passes the end of your allocation. When a number defaults to '0' you don't think twice, but when you see '3452816845" you notice.
If you are seeing them initialized to zero that would mean something other than the debug heap is setting it.
In most cases, Visual Studio will underline the uninitialized variable with green line, it often help me a lot. Besides, I will check my warnings after the build, sometime warnings will tell much information about uninitialized value.
Except the cases above, like you I am also bothered with this problem and try to avoid using 0 in my programs.
Except the cases above, like you I am also bothered with this problem and try to avoid using 0 in my programs.
Author
If you are seeing them initialized to zero that would mean something other than the debug heap is setting it.
Hmm that's strange. Even when i declare variables on the stack they are automatically initialized to 0 in debug mode.
If I step through this code in the debugger in VC2008 in debug mode, ii, jj, and qq are all zero.
int ii;
int jj;
int qq = ii + jj;
There are valid arguments on both sides of this, and I've been personally bitten before by the differences between debug and release malloc. At the same time, I do see the reasoning behind why things are the way they are.
So why not just wrap malloc and use your wrapped version instead of calling it directly? You can put whatever you want into the memory then. Always initializing variables when you declare them is also a good habit to get into (one I persoanlly don't adhere to as much as I'll admit I should though).
So why not just wrap malloc and use your wrapped version instead of calling it directly? You can put whatever you want into the memory then. Always initializing variables when you declare them is also a good habit to get into (one I persoanlly don't adhere to as much as I'll admit I should though).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
