debug versus release compiling mistery

[Dave_N]

I definitely remember a std::vector that did not check the bounds properly in release mode ... the debug stl had fixed the problem

[Sven]

Obviously changing all the DEBUG macros in your own code to DEBUG_2 (or something the compiler won't insert automatically) ...
I remember the CRT used to pass some memory errors -
the app would work properly in debug mode when there is an error - I am not sure exactly why.

Change your release build settings such that source level debug info is included in the release binary. This should not change the code being executed but it allows to run the release version in the integrated debugger. This might improve your chances to immediately see what causes the problem. If you are lucky the debugger will stop somewhere, and you get a call stack where your own code is included.

Using a DEBUG macro, using debug versions of libraries, not using compiler optimizations, and using a debugger are not necessarily connected. Usually they are, but nothing enforces that.

Sven

[Milos]

Hi friends,

Testing my engine i stumbled upon something i do real;y not understand: when compiling in debug mode my engine is completely stable but when compiling in release mode is crashes but not every run. This made me wonder what the differences are between these two compiling modes. Can anybody shed some light on this issue? Anybody any hints were to look for?

I am using visual c++ 2008 express edition

any help highly appriciated

It's very simple actually. In debug mode memory assignment is performed in much more relaxed fashion and memory is much more fragmented than in release mode. This means that in debug mode very often when array index/pointer goes out of bounds it will pass undetected (without crash) which is not the case with a release mode.
You should simply save the address of crash, and trace back to the actual assembly instruction in a release mode.

[Milos]

Change your release build settings such that source level debug info is included in the release binary. This should not change the code being executed but it allows to run the release version in the integrated debugger. This might improve your chances to immediately see what causes the problem. If you are lucky the debugger will stop somewhere, and you get a call stack where your own code is included.

You always have the address of the crash. Tracing it back into optimized assembly is fairly easy. You just need a proper debugger.

[Sven]

Change your release build settings such that source level debug info is included in the release binary. This should not change the code being executed but it allows to run the release version in the integrated debugger. This might improve your chances to immediately see what causes the problem. If you are lucky the debugger will stop somewhere, and you get a call stack where your own code is included.

You always have the address of the crash. Tracing it back into optimized assembly is fairly easy. You just need a proper debugger.

Your last sentence is the crucial one here. AFAIK, if you run a program in the VS20xx [express] debugger that carries no debug info then you don't get it to stop at the crash and tell you the address of the crash. That might work better with a different debugger. I just thought that rebuilding the release version with debug info might be simple enough in the given environment.

Sven

[Milos]

Your last sentence is the crucial one here. AFAIK, if you run a program in the VS20xx [express] debugger that carries no debug info then you don't get it to stop at the crash and tell you the address of the crash. That might work better with a different debugger. I just thought that rebuilding the release version with debug info might be simple enough in the given environment.

You are correct. VS debugger doesn't work very well without debug info (not even able to stop at the crash point). And since debug info doesn't slow program execution at all, it is really a good idea to keep it on during development (but it should be off if you plan to release a strong engine without source ).
However, even without debug info gdb is easy enough and can handle things properly .