I have a Visual Studio 2005 C++ program that runs differently in Release mode than it does in Debug mode. In release mode, there's an (apparent) intermittent crash occurring. In debug mode, it doesn't crash. What are some reasons that a Release build would work differently than a Debug build?
It's also worth mentioning my program is fairly complex and uses several 3rd party libraries for XML processing, message brokering, etc...
Thanks in advance!
Variables that are not initialized explicitly will or might not be zeroed in Release build.
In debug version often assertions and/or debug symbols are enabled. This can lead to different memory layout. In case of a bad pointer, overflow of an array or similar memory access you access in one case critical bad memory (e.g. function pointer) and in other case maybe just some non-critical memory (e.g. just a doc string is trashed)
Release build (hopefully) would run faster than your debug build. If you are using more than one thread, you might see more interleaving, or simply one thread running faster than the others, which you may have not noticed in debug build.
Release builds are usually compiled with optimisation enabled in the compiler, while debug builds usually are not.
In some languages or when using many different libraries this can cause intermittent crashes - especially when the chosen optimization level is very high.
I know that this is the case with the gcc C++ compiler, but I'm not sure about Microsoft's compiler.
I had a similar problem not long ago, which ended up being caused by the stack being treated differently in release builds. Other things that can differ:
It depends both in the compiler vendor and the libraries you compile with the DEBUG flags. While DEBUG code should never affect running code (should have no side effects) it sometimes does.
In particular, variables may be initialized only in DEBUG mode and left uninitialized in RELEASE mode. The STL in Visual Studio compilers are different in DEBUG and RELEASE modes. The idea is that iterators are fully checked in DEBUG to detect possible errors (using invalidated iterators, for example an iterator into a vector is invalidated if an insertion occurs after the iterator is retrieved).
The same happens with third party libraries, the first that I can think of is QT4, that will terminate your program with an assert if a thread different to the one that created the graphical object performs painting operations.
With all the changes, your code and memory footprint will be different in both modes. A pointer (reading the position one pass the end of an array) problem may pass undetected if that position is readable.
Assertions are meant to kill the application during DEBUG and disappear from RELEASE builds, so I would not think on assertions as being your problem. A rogue pointer or accessing one past the end would be my first suspects.
Some time ago there were problems with some compiler optimizations breaking code, but I have not read complaints lately. There could be an optimization problem there, but this would not be my first suspect.
Surviving the Release Version gives a good overview.
Things I have encountered - most are already mentioned
Variable initialization by far the most common. In Visual Studio, debug builds explicitely initialize allocated memory to given values, see e.g. Memory Values here. These values are usually easy to spot, cause an out of bounds error when used as an index or an access violation when used as a pointer. An uninitialized boolean is true, however, and may cause uninitialized memory bugs going undetected for years.
In Release builds where memory isn't explicitely initialized it just keeps the contents that it had before. This leads to "funny values" and "random" crashes, but as often to deterministic crashes that require an apparently unrelated command to be executed before the command that actually crashes. This is caused by the first command "setting up" the memory location with specific values, and when the memory locations are recycled the second command sees them as initializations. That's more common with uninitialized stack variables than heap, but the latter has happened to me, too.
Raw memory initialization can also be different in a release build whether you start from visual studio (debugger attached) vs. starting from explorer. That makes the "nicest" kind of release build bugs that never appear under the debugger.
Valid Optimizations come second in my exeprience. The C++ standard allows lots of optimizations to take place which may be surprising but are entirely valid e.g. when two pointers alias the same memory location, order of initialization is not considered, or multiple threads modify the same memory locations, and you expect a certain order in which thread B sees the changes made by thread A. Often, the compiler is blamed for these. Not so fast, young yedi! - see below
Timing Release builds don't just "run faster", for a variety of reasons (optimizations, logging functions providing a thread sync point, debug code like asserts not executed etc.) also the relative timing between operations change dramatically. Most common problem uncovered by that is race conditions, but also deadlocks and simple "different order" execution of message/timer/event-based code. Even though they are timing problems, they can be surprisingly stable across builds and platforms, with reproductions that "work always, except on PC 23".
Guard Bytes. Debug builds often put (more) guard bytes around selected instances and allocations, to protect against index overflows and sometimes underflows. In the rare cases where the code relies on offsets or sizes, e.g. serializing raw structures, they are different.
Other code differences Some instructions - e.g asserts - evaluate to nothing in release builds. Sometimes they have different side effects. This is prevalent with macro trickery, as in the classic (warning: multiple errors)
#ifdef DEBUG
#define Log(x) cout << #x << x << "\n";
#else
#define Log(x)
#endif
if (foo)
Log(x)
if (bar)
Run();
Which, in a release build, evaluates to if (foo && bar) This type of error is very very rare with normal C/C++ code, and macros that are correctly written.
Compiler Bugs This really never ever happens. Well - it does, but you are for the most part of your career better off assuming it does not. In a decade of working with VC6, I found one where I am still convinced this is an unfixed compiler bug, compared to dozens of patterns (maybe even hundreds of instances) with insufficient understanding of the scripture (a.k.a. the standard).
In my experience the most common reason seems to be that configurations differ in more ways than the release/build settings. E.g. different libs are included, or the debug build has a different stack size than the release build.
To avoid this in our Visual Studio 2005 projects we use property sheets extensively. This way the release and debug configurations can share common settings.
http://www.debuginfo.com/tips/userbpntdll.html
Due to the fact that guard bytes are added in debug builds, you may be able to "safely" access memory that is out-of-bounds for an array (particularly dynamic arrays), but this will cause an access violation in the release build. This error might go unnoticed, causing a corrupt heap and possibly an access violation in a place unrelated to the original error.
Use PageHeap (or, if you have Debugging Tools installed you could use gflags) to discover bugs related to corrupt heaps.
This post along with the links provided is very helpful in fixing related bug. adding to the above list, difference in calling conventions can also lead to this behavior - It failed in release build only with optimization for me. i declared as __stdcall and defined as __cdecl ( by default). [strangely this warning is not picked even in warn level 4 MSVC?]