I have two configuration, the Debug and Release in my project. Profiling application in debug mode gives me odd results, because some function do additional checks in DEBUG mode and it is not optimized. Profiling in release mode gives me no information about name of functions, I can see only the time spend in modul.
What is the minimum change for Release configuration to be used with profiler and to be most similar to release in performance? I mean what do I need to change in release configuration to be able to use results from profiler?
You need to compile release mode with debug symbols, follow
these instructions
Related
I'm developing my first application using GLUI and I'm having some problems. I'm using Visual Studio 2010 on a Windows 7 machine and using glui-2.35. My application runs fine when built in debug mode but crashes with a runtime error when built in release mode. From the debugger the error is from the last statement in this function from glui.cpp:
void GLUI_Master_Object::set_glutReshapeFunc(void (*f)(int width, int height))
{
glutReshapeFunc( glui_reshape_func );
add_cb_to_glut_window( glutGetWindow(), GLUI_GLUT_RESHAPE, (void*) f);
}
I'm not sure why the release build crashes; any suggestions would be greatly appreciated.
I'm not an expert in MSVC++ debug and release mode but I've been looking for some information, and in this website, some users talk about it.
One of them (#mcdeeiis), in this page, says:
...
In a debug build the complete symbolic debug information is emitted to help while debugging applications and also the code optimization is not taken into account.
While in release build the symbolic debug info is not emitted and the code execution is optimized.
Also, because the symbolic info is not emitted in a release build, the size of the final executable is lesser than a debug executable.
One can expect to see funny errors in release builds due to compiler optimizations or differences in memory layout or initialization. These are usually referred to as Release...
Anyway, check sure the libraries that GLUI or your project depends on, have been compiled with release mode too. It might cause problems.
I have build my application in release mode with debug information enabled. But I cannot debug into the MFC code for eg: CDocument::SetPathName
What should I do to step into MFC code in release mode?
This should work. You haven't provided details how exactly you "have build my application in release mode with debug information enabled" or even what version of VS you are using. You may need to specify that you want debugging info both in compiler and linker sections of your project settings.
Is there any benefit in starting a debug build without debugging (as opposed to a release build without debugging)? And what do I miss when I debug a release build (as opposed to debugging a debug build)?
Biggest advantages of debug builds (outside of the IDE):
Assertions are enabled, as is other diagnostic code you may have compiled within debug-dependent prepocessor sections.
Stack traces and variable watches are working properly, so you can have beta testers send you a crash dump and debug that in your IDE later.
Biggest disadvantages:
Slow execution, higher memory consumption, bigger file size.
Some bugs are not evident unless you compile everything with full optimization. That's because memory allocation is working differently in release builds.
Many companies distribute debug builds to alpha and beta testers and switch to release builds later.
To add to Adrians answer and as a general point when talking about debug vs. release builds:
Here are some factors that influence your builds:
You link against either the debug or the release runtime libs (/MD vs. /MDd)
NDEBUG (release mode) or _DEBUG (debug mode) is #defined
_SECURE_SCL (or some equivalent) is defined (or not)
Compiler optimizations are enabled (to some degree)
A "debug build" normally comprises _DEBUG, _SECURE_SCL=1, /MDd and all compiler optimizations disabled. This results in the "safest", "most-checked" execution mode, but also should be the slowest version you can get for your executable. The speed and safeness factors should be completely independent of whether you run your program under a debuger or not! -- The debug build gives you a maximum safety and error catching net, completely independent of whether the program is attached to a debugger.
Next comes a non-optimized release build: That is, you have all the release mode settings (NDEBUG, _SECURE_SCL=0, etc.), but you disable all compiler optimizations. This is good for testing, since performance won't be bogged down too much and you can debug this allright. Again, the usefulness of this is independent of whether you run your program under a debugger.
Finally come full optimizations. (/Ox + full inlining + possibly whole prg optimization): While this is what you would like to ship for performance reasons, chances are that you do not have enough people in your company that are actually able to debug this. That is, given a crash dump, someone most likely needs some amount of asm knowledge and what a compiler outputs to make some sense of the crash dump (or even some random breakpoint, when actually running under the debugger). Again, the pros/cons for full opt are independent of starting/running the prg under a debugger.
Starting a debug build without debugging can give you for example the following benefit: if a contrainer is indexed with an invalid index you'll get an assertion failed, in release mode you'll get undefined behavior. That's one thought. What you miss when debugging in release mode is that there is no correspondence between source lines and assembly code any more because the optimizer has run. So it's far more difficult to debug in release mode
I'll offer a recent experience that I can't explain -- sometimes when I run my application, I get unhandled exceptions when running in the IDE. The problem is, I know my exception is getting handled, and I also know that I'm not breaking on thrown exceptions (via CTRL-D, E). If I hit F5 several times, my error handler eventually catches the exception and deals with it properly.
The reason for this has eluded me for several weeks, so when I don't want the execution to get interrupted, I run outside of the IDE and simply attach to the process later if I need to.
If you really need to see the Debug output while running outside of the IDE and you're not using something like log4net to capture everything, you can use DebugView instead.
i have strange problem , my application (exe) is working fine in debug mode in windows 7
but stop to work with exception when compiling in release mode .
how can i debug the program to find what is causing the exception this is application with more then 300,000 lines of code ..
Compile in Release mode but create the .pdb files: How to generate PDB’s for .net managed projects in release mode?
Deploy the .pdb files to same folder as the .exe.
Then attach to process.
Check the projects settings which are different for debug and release modes, maybe you will find an answer there.
Compile release mode with debug information and turn off optimization. You will have debug version compiled with release defines. If it fails the debugger will show you bad place.
Just turn off optimization. Once upon a time that was an issue for me. In this case it will be really hard to find out the cause.
Create PDBs, it can be done for native C++ too.
In visual studio or any other IDE, usually there are two build configurations, Debug and Release?
How does the differ? Why sometimes you have compile errors when building in Debug mode, but not when in Release mode, and vice versa?
Debug compiles with symbols and allows you to "see" your code when it runs. It also does some initialization of variables to help in the bug tracking process.
Release is generally optimized, and does not generate debug data.
Generally when you get compile issues toggling between the two, it relates to hard coded paths to folders.
MSDN on configurations
The debug build is created with some embedded information (symbols) which allows the debugger to debug the application and exposes the runtime behavior of the application. On the down side, the debug build is a bit slower and inefficient in execution and has a bigger memory footprint.
Source:http://www.programmersheaven.com/2/FAQ-VISUALSTUDIO-Debug-Release