Release /Debug hell, with V-studio C++ project

Question

I'm so tired of this happening. I'm working in Visual studio using C++, and go a little to far in developemnt before attempting a release build/run cycle, only to find my release build crashes. It leaves me no way to fix the problem beyond to hack out big chunks of code looking for all potential violators. Anyway, If I go into my "release" project properties and enable the debug database for "Edit and Continue", and DON'T even enable Debugging in the linker, the Release version runs perfectly.

OK, I do appreciate any input as to what kinds of thing to look for to properly get my Release version to work, but dare I ask this question: "Who Cares"? I understand that if the linker does in fact link with DEBUG versions of runtime and windows libraries, that the program probably won't run on any system that doesn't have VStudio installed. But what about what I'm doing... just letting the compiler DEBUG format set to "Program Database for Edit & Continue (/ZI)". It hardly makes a 1K difference in the sixze of the application, and if it won't stop the EXE from working, maybe I should just leave it set that way? Or am I asking for trouble?

--Randy

Answer 1

I think you need to identify what practices/code you have that cause crash in Debug but not Release.

If you can figure that out, you can identify what you need to do differently.

In addition, "I'm working in Visual studio using C++, and go a little to far in developemnt before attempting a release build/run cycle" indicates to me that you might want to develop more discipline in your development practice. You might want to spend a bit of time learning some test-driven development techniques; I found that those improved my code/compile defect rates.

Answer 2

I use a single build instead of separate debug and release builds: see "Separate ‘debug’ and ‘release’ builds?"

There are normally several differences between debug and release builds, e.g:

• Which version of the run-time libraries?
• Compiler optimizations?
• Incremental linking?
• Edit and continue?
• Symbolic debug information?

You can in fact use these in any combination. The only thing that would stop your software running on a clean machine would be using the debug versions of the run-time libraries.

I usually switch off edit-and-continue, and incremental linking, because I've found these to be buggy in the distant past.

Answer 3

"Who cares?" ... well, you should.

The fact that the release build crashes indicates there is something wrong with it.

If turning on debug symbols "fixes" it, then you have a magic fix that you don't understand. Why does it fix it? Can you rely on this fix working on every PC your software is installed on?

The symptoms you describe suggest that you are corrupting memory somewhere (a buffer overrun error most likely) and that addition of debugging symbols rearranges or pads out your code in such a way that you can "get away with it" because the memory corruption doesn't happen to hit anything vital.

But you can't really rely on such a fix. It undermines all confidence in your application, and it will bite you one day (such a fix could easily stop "working" the next time you compile your app)

You need to isolate what it is that causes this problem - if it happens more than once then you haven't learned anything from the last time you fixed it. It's not "normal" for an application to run in debug but not in release, so there must be something you're doing wrong - you need to work out what it is and fix it so that you avoid such bugs in future. (e.g. If it's a buffer overrun it may simply be that you are allocating a buffer of "n" elements and then accessing element "n" - you should only access elements 0 to (n-1). THis is very easy to fix once you understand how to write such code... but you have to put in a bit of effort to work out what it is youre doing wrong)

Answer 4

Yes, you're asking for trouble. From the sound of things, you're writing code that contains undefined behavior, and happens to (at least appear to) work under certain circumstances -- but it's still almost certainly wrong (yes, some compilers have optimization bugs so correct code doesn't work when optimized -- but these are fairly rare).