I've got a little problem. my application runs without problems in Debug mode, but crashes in release mode. I can't track down the problem, because in release mode all the Debuginfo appears to be nonsense. However - sometimes in other projects the Debug output is also valid in release mode. What projectsettings do I have to change such that the Debug output is valid in release?
thanks!
Even in Release mode "Generate Debug Info" should be set to "Yes" per default. The problem is that when you're running in Release Mode the compiler optimizes the code which makes it hard for the debugger to display the correct values of variables (it may for instance choose to keep some variables in registers etc.).
There's not much to be done about this, you could always turn off optimization either globally or around a specific function using #pragma optimize ("", off) / #pragma optimize ("", on) around it but this essentially means you're running in Debug Mode again and the crash will probably go away...
If you're comfortable with reading assembly code, you can switch over to disassembly mode and through a little investigation find the correct values of your variables.
Likely, you're making use of uninitialized variables.
In your project settings, set
Configuration Properties > C/C++ > General > Debug Information Format
to Program Database
Then, set
Configuration Properties > Linker > Debugging > Generate Debug Info
to Yes
The good old "debugging with traces" approach may help you having a rough idea of where the problem is. Then read this portion of the code again and chase uninitialized variables.
Related
What is difference in debugging in debug mode and release mode?
In release mode the symbols table that is loaded contains less information of symbols which means less debugging information. But, if we set "Disabled (/Od)" in C/C++->Optimization->Optimization then I could not see any difference in two debugging type.
Is there any difference in debug mode and release mode(with Optimization Disabled)?
There's very little magic to it. Debug and Release are simply names assigned to a set of compiler options. The most relevant option for the Debug configuration is the /Od option, it disables the optimizer so your code is easier to debug.
Clearly you can always change the Release configuration options to resemble the Debug configuration options. Like disabling the optimizer. Now there's no relevant difference anymore between them and the Release configuration behaves a lot like the Debug configuration in the debugger.
Other options normally used in the Debug configuration that affects your code:
the _DEBUG macro is defined, asserts will fire
function inlining is turned off
the /RTC option is turned on, very good at catching bugs in your code
the _HAS_ITERATOR_DEBUGGING macro is defined, catching bugs in code that uses STL classes
you'll link with the debug build of the CRT, enabling asserts in that build
the debug allocator will be enabled, assuming you #included crtdbg.h
edit + continue support is turned on, a side effect is much bigger stack frames
I'm trying to debug a program, but initializing (loading data) takes very long time in Debug mode (more than 10 minutes) where as it takes milliseconds in release mode.
Is there an easy way to compile the unimportant cpp file in Release mode, while the rest of the program in Debug mode?
I've tried changing the properties of the cpp file from Optimization Disabled (/Od) to Maximize Speed (/O2) but then I get this error 1>cl : Command line error D8016: '/O2' and '/RTC1' command-line options are incompatible
Yes you can. There's nothing stopping you from switching some projects to release mode and others to debug, assuming you actually have different projects and they produce dynamically linked libraries (dlls). Not too sure if this works with statically linked libraries too.
It might be also nice to know that you can debug your optimized-for-speed build by turning on debug symbols in the linking phase (project->properties->linker->debuggin->"Generate debug info":"optimize for debugging". It will not show all variables and doesn't let you jump into inlined functions but it does let you debug slow programs.
I have a code of a Plug In from an SDK.
The code is in Debug Mode.
I use Intel Compiler which only applies optimizations in Release Mode.
Under configuration manager of the project only "Debug" mode is defined.
How could I switch to "Release" mode and enable all Intel Compiler's optimizations?
If I enable them on debug mode nothing is applied (Empty Report).
I couldn't find the trick to do so.
Thank You.
P.S.
I do use the /MT switch yet still.
Project configurations are managed by the user, so you can create Release configuration by yourself if it's missing. In the insides, they can differ by compiler options and defines, mostly. When I had very slow PC, I sometimes used configuration I've created, obviously named Debug_Optimized.
For example, Debug configuration usually has DEBUG defined. It makes some lines of code comment out, to speed up the resulting program.
You can usually speed up creation of another configuration by basing it on existing one. Look for all "Perfomance" and "Optimizations" tabs and set them according to your needs. There usually isn't one best configuration (sometimes "optimize for size" is faster than "optimize for speed"). Try these options out.
Ok, here is the solution,
First of all using the /MD or /MD, which is trivial.
Then define NDEBUG.
Pay attention to do this in every file in the project.
In my case, some files were set to /MTd which sets the Debug mode.
I used Intel Compiler and this thread might help:
http://software.intel.com/en-us/forums/topic/328136
I'm having a strange issue with unit testing in Visual Studio 2010.
I have a test that passes when I use "Debug test" (without any breakpoints), but failes when I use "Run test".
This test uses external dll's, so I can't debug it properly.
Do you know of any reason why a situation like this is possible?
Why "Debug test" is different than "Run test", when all other parameters are the same?
Switch you solution to Release mode instead of Debug, run a full build, switch back to debug and retry and let me know the outcome, I think the tests will pass....
There can be several reasons, but to pin-point one, you'll have to give us some code to work with.
It could be code exclusion:
#ifdef _DEBUG
//do something
#endif
This will only be executed in debug mode.
It could be optimizations. Although they shouldn't normally affect the behavior, you shouldn't rely on destructors or copy constructors being called.
If you're doing any hacking inside the code, it might also only be valid for debug.
I'd suspect that you are accessing memory out of bounds. One major difference between debug and release is that debug adds kits if padding and special markers to memory allocations to catch certain kinds of errors. This means the memory layouts are often very different between debug and release builds. I would suspect that you are accessing memory out of bounds in a way that the debugger isn't catching, where you find an accidentally valid value in the debug version, but an invalid one in the release version.
I have a workspace for running an H.263 Video Encoder in a loop for 31 times i.e. the main is executed 31 times to generate 31 different encoded bit streams. This MS Visual Studio 2005 Workspace has all C source files. When i create a "DEBUG" configuration for the workspace and build and execute it, it runs fine, i.e. it generates all the 31 output files as expected.
But when I set the configuration of the workspace to "RELEASE" mdoe, and repeat the process, the encoder crashes at some test case run.
Now to debug this is verified following:
Analyzed the code to see if there was any variable initialization being missed out in every run of the encoder
Checked the various Workspace(Solution) options in both the modes (DEBUG and RELEASE).
There are some obvious differences, but i turned the optimization related options explicitly same in both modes.
But still could not nail the problem and find a fix for that. Any pointers?
-Ajit.
It's hard to say what the problem might be without carefully inspecting the code. However...
One of the differences between debug and release builds is how the function call stack frame is set up. There are certain classes of bad things you can do (like calling a function with the wrong number of arguments) that are not fatal in a debug build but crash horribly in a release build. Perhaps you could try changing the stack frame related options (I forget what they're called, sorry) in the release build to the same as the debug build and see whether that helps.
Another thing might be to enable all the warnings you possibly can, and fix them all.
Could be a concurrency problem of two threads. The DEBUG configuration slows the execution down, so the problem does not occur. But, only a guess.
Interesting problem.. Are you sure you have no conditional compilation code lurking around that is not being compiled in release mode? i.e:
#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif
Thats the only thing I can really think of.. Never experienced anything like this myself..
Can you add the debug symbols to the release build and run it in the debugger to see where and why it crashed?
Yeah, those bastard crashes are the hardest to fix. Fortunatly, there are some steps you can do that will give you clues before you resort to manually looking at the code and hope to find the needle.
When does it crash? At every test? At a specific test? What does that test does that the others don't?
What's the error? If it's an access violation, is there a pattern to where it happens? If the addresses are low, it might mean there is an uninitialised pointer somewhere.
Is the program crashing with Debug configuration but without the debugger attached? If so, it's most likely a thread synchronisation problem as John Smithers pointed out.
Have you tried running the code through an analyser such as Purify? It's slow but it's usually worth the wait.
Try to debug the release configuration anyway. It will only dump assemblies but it can still give you an indication of what happens such as if the code pointer jumps in the middle of garbage or hits a breakpoint in an external library.
Are you on an Intel architecture? If not, watch for memory alignement errors, they hard crash without warning on some architectures and those codec algorithm tend to create those situations a lot since they are overly optimized.
Are you sure there are no precompile directives that, say, ignores some really important code in Release mode but allows them in Debug?
Also, have you implemented any logging that might point out to the precise assembly that's throwing the error?
I would look at the crash in more detail - if it's crashing in a test case, then it sounds pretty easily reproducible, which is usually most of the challenge.
Another thing to consider: in debug mode, the variables are initialized with 0xCCCCCCCC instead of zero. That might have some nasty side effects.