Jump to content
  • Advertisement
Sign in to follow this  
indigox3

initializing variables in debug mode

This topic is 2711 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites

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....)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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;

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!