How to debug uninitialized variables in release mode in C++.
-
1Why would you want to do that? – Luxspes Sep 20 '10 at 03:22
-
1Do the errors not show up when running a debug build, attached to the debugger? – James McNellis Sep 20 '10 at 03:27
-
No I just want to know. If I dont have a debugger how to do debug uninitialized variables – brett Sep 20 '10 at 03:27
-
Get into the habit of initializing all of your variables to some value the moment they come into existence (e.g. use initializer lists for class members). – In silico Sep 20 '10 at 03:37
-
1Turn up the warning level as high as it will go. Then tell the compiler to treat all warnings as errors. – Martin York Sep 20 '10 at 03:55
7 Answers
There's a warning for this. You should try to always compile cleanly at the highest warning level. For VC++ this is level 4. Turn off specific annoying warnings selectively only.
Also, unless you deliberately uncheck the option, VC++ will compile with /RTCu
(or even /RTCsu
) which puts in checks to catch uninitialized variables at run-time.
Of course, proper programming style (introduce variables as late as possible) will prevent such errors from happening in the first place.

- 219,715
- 46
- 258
- 445
I don't know about VC++, but for gcc, there is a warning option -Wuninitialized
that can be used while compiling. Details: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Append: -Wuninitialized
is included in -Wall
, i.e warn all, one of the recommended and most used warning flag. In addition, having -Werror
would fail the compilation whenever any such warning arises.

- 19,750
- 10
- 51
- 60
-
1Visual C++ will usually issue a level 1 warning (C4700) if an uninitialized variable is used; it's not always possible for the compiler to figure out that the variable is uninitialized, so it's not a 100% solution. – James McNellis Sep 20 '10 at 03:35
Generally, rather than debugging uninitialized variables, you want to prevent the very possibility, such as using classes/objects with ctors, so creating one automatically and unavoidably initializes it.
When you do use something like an int
, it should generally be initialized as it's created anyway, so uninitialized variables will be pretty obvious from simple inspection (and you generally want to keep your functions small enough that such inspection is easy).
Finally, most decent compilers can warn you about at least quite a few attempts at using variables without initialization. Clearly such warnings should always be enabled. One important point: these often depend on data-flow analysis that's intended primarily for optimization, so many compilers can/will only issue such warnings when you enable at least some degree of optimization.

- 476,176
- 80
- 629
- 1,111
Uninitialized variables are a nasty bug to find. Some static checkers would probably be able to find your uninitialized variable. There are open source ones. You might be able to get a trial version of commercial version as well.

- 9,673
- 6
- 31
- 51
-
5Uninitialized variables are not set to zero; they are initialized to special fill patterns, `0xcc` and `0xcd` (depending on whether the memory was allocated on the stack or the debug heap). The debugger can also be configured to break when uninitialized memory is read (though there are probably some restrictions on when this feature can be used). – James McNellis Sep 20 '10 at 03:32
-
@James McNellis - Are you sure about debug mode in VC++? In my experience they are set to zero in debug mode. But that could have been earlier versions. Maybe versions these days set them to fill patterns (that would make more sense IMHO). – Starkey Sep 20 '10 at 03:35
-
Yes; those fill patterns have been used since at least Visual C++ 2005. – James McNellis Sep 20 '10 at 03:36
-
Well you learn something new every day. I haven't used VC++ in a while. Thanks for the info. I removed the sentence about the zero setting. – Starkey Sep 20 '10 at 03:37
-
If you do not have debugger, you need to add logging statements in your code wherever you want to see the values of variables which you suspect uninitialized.
Sometimes, logging statement may lead to crash if passed an uninitialized pointer. So you can catch the bug there itself in this case.

- 6,144
- 9
- 44
- 66