Code crash in MS Visual Studio 2005 in RELEASE configuration

Question

Hi,

I have a workspace for running an H.263 Video Encoder in a loop for 31 times i.e. the main is executed 31 times to generate 31 different encoded bit streams. This MS Visual Studio 2005 Workspace has all C source files. When i create a "DEBUG" configuration for the workspace and build and execute it, it runs fine, i.e. it generates all the 31 output files as expected. But when I set the configuration of the workspace to "RELEASE" mdoe, and repeat the process, the encoder crashes at some test case run.

Now to debug this is verified following:

1. Analyzed the code to see if there was any variable initialization being missed out in every run of the encoder
2. Checked the various Workspace(Solution) options in both the modes (DEBUG and RELEASE).

There are some obvious differences, but i turned the optimization related options explicitly same in both modes.

But still could not nail the problem and find a fix for that. Any pointers?

-Ajit.

Answer 1

Are you sure there are no precompile directives that, say, ignores some really important code in Release mode but allows them in Debug?

Also, have you implemented any logging that might point out to the precise assembly that's throwing the error?

Answer 2

It's hard to say what the problem might be without carefully inspecting the code. However...

One of the differences between debug and release builds is how the function call stack frame is set up. There are certain classes of bad things you can do (like calling a function with the wrong number of arguments) that are not fatal in a debug build but crash horribly in a release build. Perhaps you could try changing the stack frame related options (I forget what they're called, sorry) in the release build to the same as the debug build and see whether that helps.

Another thing might be to enable all the warnings you possibly can, and fix them all.

Answer 3

Could be a concurrency problem of two threads. The DEBUG configuration slows the execution down, so the problem does not occur. But, only a guess.

Answer 4

Interesting problem.. Are you sure you have no conditional compilation code lurking around that is not being compiled in release mode? i.e:

#if (DEBUG)
// Debug Code here
#else
// Release Code here
#endif

Thats the only thing I can really think of.. Never experienced anything like this myself..

Answer 5

I would look at the crash in more detail - if it's crashing in a test case, then it sounds pretty easily reproducible, which is usually most of the challenge.

Answer 6

Can you add the debug symbols to the release build and run it in the debugger to see where and why it crashed?

Answer 7

Also to consider: in debug mode, the variables are initialized with 0xCCCCCCCC instead of zero. That might have some nasty side effects.

Answer 8

Yeah, those bastard crashes are the hardest to fix. Fortunatly, there are some steps you can do that will give you clues before you resort to manually looking at the code and hope to find the needle.

When does it crash? At every test? At a specific test? What does that test does that the others don't?

What's the error? If it's an access violation, is there a pattern to where it happens? If the addresses are low, it might mean there is an uninitialised pointer somewhere.

Is the program crashing with Debug configuration but without the debugger attached? If so, it's most likely a thread synchronisation problem as John Smithers pointed out.

Have you tried running the code through an analyser such as Purify? It's slow but it's usually worth the wait.

Try to debug the release configuration anyway. It will only dump assemblies but it can still give you an indication of what happens such as if the code pointer jumps in the middle of garbage or hits a breakpoint in an external library.

Are you on an Intel architecture? If not, watch for memory alignement errors, they hard crash without warning on some architectures and those codec algorithm tend to create those situations a lot since they are overly optimized.