My code works in Debug mode, but not in Release mode.

views:

356

answers:

My code works in Debug mode, but not in Release mode.

Hi,

I have a code in Visual Studio 2008 in C++ that works with files just by fopen and fclose. Everything works perfect in Debug mode. and I have tested with several datasets. But it doesn't work in release mode. It crashes all the time. I have turned off all the optimizations, also there is no dependency to anything(in the linker), and also I have set these:

Optimization: Disabled(/Od) Keep Unreferenced Data. Do Not Remove Redundant Optimize for Windows98: NO

I still keep wondering how it should not work under these circumstances. What else should I turn off to let it works as in debug mode?

I think if it works in release mode but not in debug mode, it might be a coding fault but the other way looks weird. isn't it?

I appreciate any help. --Nima

+2 A:

Debug modes often initialize heap data allocations. The program might be dependent on this behavior. Look for variables and buffers that are not getting initialized.

Amardeep 2010-05-27 18:07:26

I double checked, I don't see any mistakes like that. :)

Nima 2010-05-27 18:13:58

One more thing to check for is the possibility that the buffers you are using for fread() are large enough. Buffer overruns might be tolerated in one build configuration but not another simply due to how things get arranged in memory and the somewhat different heap usage in debug vs. release.

Amardeep 2010-05-27 18:24:47

Your answer looks promissing but I couldn't locate the exact location of the issue. Trying to debug in release mode doesn't help since it jumps some parts of the code and suddenly crashs. I tried scaffolding(putting couts...) and here it happens:Obj* f(...){ Obj* obj= new Obj(..);... cout<<"1"<<endl; return obj;}void main(){ Obj *obj = f(...); cout<<"2"<<endl;}it prints 1 but not 2!

Nima 2010-05-27 18:57:49

Okay, that does sound like a buffer overrun. It would be happening in the constructor of Obj. Check if there is a stack buffer in there. If it overruns the stack it will overwrite the return address of f() then the return obj; call would explode.

Amardeep 2010-05-27 20:58:30

1) Double check any and all code that depends on preprocessor macros.
2) Use assert() for verify program state preconditions. These must not be expected to impact program flow (ie. removing the check would still allow the code to provide the same end result) because assert is a macro. Use regular run-time conditionals when an assert won't do.
3) Indeed, never leave a variable in an uninitialized state.

Geoff 2010-05-27 18:09:29

1. There isn't any.2. I'm not using assert().

Nima 2010-05-27 18:14:44

1) :)2) Starting with assert from the very beginning would have helped you catch this problem very early on. :)

Geoff 2010-05-27 18:20:59

By far the most likely explanation is differing undefined behavior in the two modes caused by uninitialized memory. Lack of thread safety and problems with synchronization code can also exhibit this kind of behavior because of differing timing environments between debug and release, but if your program isn't multi-threaded then obviously this can't be it.

bshields 2010-05-27 18:24:15

ansaurus

tags:

views:

answers:

My code works in Debug mode, but not in Release mode.

related questions