Debugging a bug that's in release mode only...
Author
I got a very weird situation going on with the software I write professionally. The issue is that when we run it in release mode, a bug pops up, which looks related to an improperly initialized variable after running a few calculation sets. The bug happens in very specific cases, and is unreproducible in a debug build of the software.
I tried enabling debug symbols on the release build, but due to all sorts of copy protection schemes, the p.o.s doesn't run when built from within the IDE. It requires me to do all sorts of post build steps, which require quite some additional work to get working at the moment.
Is there some way for me to disable the automatic initialization of variables in debug mode? I'm working with VC++ 2008 Professional.
Toolmaker
Preventing debug initialization depends on where these variables are allocated - heap data, static data (globals, etc), or on the stack.
1. Heap is the most awkward. Firstly you must link with the release CRT libraries ("Runtime Library" in the C/C++ Code Generation settings) as the debug ones initialize heap allocations. Once you've done that you also need to start the process without the debugger attached as Windows also initializes the heap for you. You can attach the debugger (using the debug menu) right after it's started so you can actually debug.
2. Statics & globals I believe will always get zero initialized, so you can't control that.
3. Stack variables are controlled with the run time check compiler options (/RTC*) "Basic runtime checks" in the C/C++ Code Generation options.
If that doesn't help then I'd suggest making a new build configuration, probably based on the debug one, but with the settings as close as possible to the release settings (avoiding anything that brings in the copy protection stuff, and with debug info on of course).
1. Heap is the most awkward. Firstly you must link with the release CRT libraries ("Runtime Library" in the C/C++ Code Generation settings) as the debug ones initialize heap allocations. Once you've done that you also need to start the process without the debugger attached as Windows also initializes the heap for you. You can attach the debugger (using the debug menu) right after it's started so you can actually debug.
2. Statics & globals I believe will always get zero initialized, so you can't control that.
3. Stack variables are controlled with the run time check compiler options (/RTC*) "Basic runtime checks" in the C/C++ Code Generation options.
If that doesn't help then I'd suggest making a new build configuration, probably based on the debug one, but with the settings as close as possible to the release settings (avoiding anything that brings in the copy protection stuff, and with debug info on of course).
Just out of curiosity, what about enabling 'debug informations' in a realease build? Wouldn't that make you able to debug the code without all other debugging stuff?
Quote:Original post by ToohrVyk
Try /RTCs.
This hasn't worked the few times I tried it. Only setting the CRT Library Runtimes to Release did. It does seem to report at compile-time if my variables are not initialized, however. YMMV.
Author
I figured out the bug, by old fashioned log style debugging. Turns out, it was caused by a gigantic set of uninitialized variables on a piece of 7 year old code. The bug only occurred under Windows XP, because the Windows 6.0/6.1 kernel immediately re-uses the released memory in it's cache.
The bug was reproducible when I started a new project after doing calculations in a previous project with much higher ceiling values. The new project would be placed at the same memory location as the old project, and thus have a 'valid' value in the one of the variables, which was then used. Properly initializing the variable did solve the problem, altho I find it rather odd that a lot of these variables are never initialized during the runtime of the class...
Toolmaker
The bug was reproducible when I started a new project after doing calculations in a previous project with much higher ceiling values. The new project would be placed at the same memory location as the old project, and thus have a 'valid' value in the one of the variables, which was then used. Properly initializing the variable did solve the problem, altho I find it rather odd that a lot of these variables are never initialized during the runtime of the class...
Toolmaker
Try gflags (google it) to debug better in release mode. When it's installed, type in a terminal:
cd C:\Program Files\Debugging Tools for Windows
GFlags.exe /i YOURAPPNAME.exe +hpa
When done, don't forget to restore your system to normal by doing
GFlags.exe /i YOURAPPNAME.exe -hpa
cd C:\Program Files\Debugging Tools for Windows
GFlags.exe /i YOURAPPNAME.exe +hpa
When done, don't forget to restore your system to normal by doing
GFlags.exe /i YOURAPPNAME.exe -hpa
Quote:Original post by Toolmaker
altho I find it rather odd that a lot of these variables are never initialized during the runtime of the class...
Are they ever read from?
Quote:Original post by cignox1
Just out of curiosity, what about enabling 'debug informations' in a realease build? Wouldn't that make you able to debug the code without all other debugging stuff?
That might work, but enabling debug information pushes data around to different memory addresses so your bug may no longer repro.
The act of debugging can make it so that your bug doesn't reproduce anymore - a heisenbug :P
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
