Hey all. I've got a bug in my code and I believe it's because I foolishly forgot to initialize a member variable somewhere. It crashes in Release, but I can't get it to crash in Debug mode.. and I have no idea where to start looking.
What I'd like is to stop Debug mode from automatically initializing my member variables. If my theory is correct, the program will crash and I can get a better idea of what variable is causing the problem. How can I change my project settings to make this happen?
Cheers,
Ben.
How can I stop Visual C++ Debug mode from initializing variables?
You could try compiling the program in release configuration (optimized), but with debug information on.
I don't think there's a setting to do exactly what you want, but I think you can do the same thing by debugging a release build. Change the release build settings to generate debug information so you get a pdb, then just debug the release build.
This should also mean that the debugger will pause the program when the crash occurs and show code close to you the problem.
edit: ninja'd
This should also mean that the debugger will pause the program when the crash occurs and show code close to you the problem.
edit: ninja'd
Author
OK, I just tried to set that up by creating a new configuration, copying the settings from Release mode, and then in the new configuration changing:
Configuration Properties > C/C++ > General > Debug Information Format to "Program Database for Edit and Continue (/ZI)". It was originally "Program Database (/Zi)". Doing this however won't let me compile because it's not compatible with (/Ox), which is Full Optimization found: Configuration Properties > C/C++ > Optimization > Optimization. I don't want to change that however as it defeats the purpose, doesn't it?
Am I not supposed to set (/ZI), but set something else instead?
Cheers.
Configuration Properties > C/C++ > General > Debug Information Format to "Program Database for Edit and Continue (/ZI)". It was originally "Program Database (/Zi)". Doing this however won't let me compile because it's not compatible with (/Ox), which is Full Optimization found: Configuration Properties > C/C++ > Optimization > Optimization. I don't want to change that however as it defeats the purpose, doesn't it?
Am I not supposed to set (/ZI), but set something else instead?
Cheers.
You're probably overwriting the end of an array. In debug mode the memory allocator sets aside more space which means you typically get away with overwrites. Using something like _CrtCheckMemory may help (although sometimes it's more subtle, like missing off a null terminator, so you never write somewhere invalid, just attempt to read from it), but manually checking any low-level buffer or string manipulation would be a good idea also.
Author
Well, the reason I think it's an uninitialized variable is because the program doesn't crash.. it freezes. So I'm guessing that a while loop is going and instead of doing it 10 times.. it's doing it 13908709187234 times or something.
You can control it by enabling/disabling the Stack Frames run time check option. In VS2008 it's at Configuration Properties -> C/C++ -> Code generation -> Basic Runtime Checks.
Quote:Original post by bencelot
Am I not supposed to set (/ZI), but set something else instead?
Yeah, you don't need 'edit and continue'. As long as you're generating a pdb for the release build, you should be able to debug it. Be aware that leaving optimisations on will make what the debugger tells you suspect.
If I were you I'd try the time honoured technique of pausing the program while it's frozen and see where you end up. Do it a few times to be sure.
Edit: Once you know the area of code you're interested in, add some quick logging to console / file / debug output to check the values you're interested in. Don't trust the debugger!
Quote:Original post by adeyblue
You can control it by enabling/disabling the Stack Frames run time check option. In VS2008 it's at Configuration Properties -> C/C++ -> Code generation -> Basic Runtime Checks.
That's awesome, thanks!
Quote:Original post by bencelot
Well, the reason I think it's an uninitialized variable is because the program doesn't crash.. it freezes. So I'm guessing that a while loop is going and instead of doing it 10 times.. it's doing it 13908709187234 times or something.
In that case while that is happening, go to the debug menu in Visual Studio and select the "Break All" option. That will stop the program and let you see where it is stuck.
Note that in release mode you can't always trust what the debugger tells you about variables, so once you've found where it is stuck I'd start adding some debug output code to find out what's going on unless it's obvious.
Author
So adeyblue, I see I can set Basic Runtime Checks to "Uninitialized variables (/RTCu)". Should that be used in Debug mode or Release mode? Because in debug mode, might the variables already be initialized anyway?
Also another question.. my release version currently has the Debug Information Format set to "Program Database (/Zi)". If this is debuggable, does this mean that my Release version has been debuggable this entire time and running slower than it could've been? If I disable this (perhaps by setting it to "C7 Compatible (/Z7)") will that improve the performance of my Release build?
Also another question.. my release version currently has the Debug Information Format set to "Program Database (/Zi)". If this is debuggable, does this mean that my Release version has been debuggable this entire time and running slower than it could've been? If I disable this (perhaps by setting it to "C7 Compatible (/Z7)") will that improve the performance of my Release build?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
