How to debug in release mode?

Question

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.

Exploration

Answer 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:

• How to: Debug a Release Build
• OPT Optimizations

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.

Misbeliever

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? – Exploration

@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. – Misbeliever

@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. – Ossification

Because those lines don't exist in the release build. They've been optimized out. – Misbeliever

@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. learn.microsoft.com/en-us/visualstudio/code-quality/… – Nissensohn

Even if we change the configuration settings like this, sometimes the Visual Studio debugger does not point to the right line where the error occurs. If that's the case, we'd better try changing the optimization setting to less optimize or disable, which may make the debugger find the right line of the problem. Seems like @YochaiTimmer mentioned this too, in the other answer. – Tytybald

Answer 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

Tweedsmuir

@Ed s answer is great if you have access to code and IDE. Yochai's answer worth reading. – Reichert

This answer should be noted. Just simply following the other answer(MSDN) won't let your debugger always show the right line of the problem. Sometimes we should change the optimization setting, to make the debugger show the right info. (In Visual Studio, for example: property page -> C/C++ -> Optimization -> Optimization 'Disabled') – Tytybald