What are some reasons a Release build would run di

Question

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!

Answer 1

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.

http://support.microsoft.com/?id=286470

Answer 2

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:

• Memory allocation is handled differently with debug builds in the VS compiler (ie, writing 0xcc over cleared memory, etc.)
• Loop unrolling and other compiler optimizations
• Alightment of pointers

Answer 3

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)

Answer 4

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.

Answer 5

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.

Answer 6

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.