How to debug in release mode?

41,346

Solution 1

In VS, right click your project, chose "Properties".

  1. Click the C/C++ node. Set Debug Information Format to C7 compatible (/Z7) or Program Database (/Zi).

  2. Expand Linker and click the General node. Set Enable Incremental Linking to No (/INCREMENTAL:NO).

  3. Select the Debugging node. Set Generate Debug Info to Yes (/DEBUG).

  4. Select the Optimization node. Set References to Yes (/OPT:REF).

    if /OPT:REF is specified, /OPT:ICF is on by default.

That's ripped directly from Microsoft's documentation:

I do this all of the time and pretty much never debug in debug mode anymore. As you know, many errors that occur in a release build may not occur in a debug build (almost certainly the errors that arise from invoking UB).

Also, I work on a project which uses a ton of image processing and performs a lot of compression/decompression of large images. Using a slow debug build is simply impractical.

Solution 2

You can't always just change the project settings and recompile.
Sometimes you have a released version which you would like to debug, or a dump file sent by a client.

When compiling a C++ project in release with optimizations, the debugger sometimes doesn't show the right object information.

The local variables are usually the first to go, and many times, the this object's information is lost to the debugger.

The reason is that the compiler uses the available hardware registers to hold the information, and uses optimizations to avoid allocation of local variables.

I've suggested a way to find the missing information here:

Debugging Release Projects in C++ - Finding the Lost Object Information

Share:
41,346
Pedro
Author by

Pedro

Updated on July 09, 2022

Comments

  • Pedro
    Pedro almost 2 years

    I have to debug a c++ project, but as one dependency doesn't compile in debug mode and I haven't been able to fix that issue so far, I'd like to try to debug the project in release mode.

    Currently the application crashes due to a null pointer, but I haven't the code that's causing the error. As break points apparently are ignored in release-mode, I'd like to know what's the best way find the error.

  • Pedro
    Pedro almost 12 years
    thanks problem solved! I don't know very much about the effects of all these settings, so is better to only use them for debugging and remove them again when compling an actual release version?
  • Ed S.
    Ed S. almost 12 years
    @Pedro: Yes, it's probably best to revert them and leave the default values for release ON. I usually create a new build type for this configuration, i.e., "release w/symbols". That said, it can't hurt to go study what those switches actually do.
  • Muhammet Ali Asan
    Muhammet Ali Asan over 7 years
    @Ed s answer is great if you have access to code and IDE. Yochai's answer worth reading.
  • Olorin
    Olorin almost 5 years
    @EdS. Well that (in fact an adaptation of it to intel visual fortran) made my day ! (I created a new config by copying from release, and changed what needed to be changed.) I understand why doing F10 doesn't execute the code linearly (I guess that some other optimization still occur) but what I don't understand is why some lines are passed over several times, like declarations/initializations etc.
  • Ed S.
    Ed S. almost 5 years
    Because those lines don't exist in the release build. They've been optimized out.
  • userom
    userom over 4 years
    @Eds: Thanks. Well for sure this worked. I had unexpected crash in release mode. Many of my functions are overshooting stack limit of 16KB and I was suspecting that could be reason (warning C6262). But before doing any self optimization, I modified build properties with /OPT:REF in release and it just ran. I guess C6262 removal is important too. docs.microsoft.com/en-us/visualstudio/code-quality/…