Hello everybody, My game runs correctly in debug mode but crashes in release mode. I have already disabled optimizations for release mode. The only difference between 2 modes is that there is 1 warning in release mode: LINK : warning LNK4089: all references to "SHELL32.dll" discarded by /OPT:REF I have no idea on this problem. Can anyone help? Thanks. Frank

That just means the dll was included in the project link settings but you aren''t referencing anything in there, so it is ignoring it. Those get put in there by default. Definitely not the cause of your problems. Usually differences in release and debug behaviour point to memory problems of some kind. In debug it is much more forgiving about those. Use a memory checking tool like BoundsChecker is probably the quickest way to find it.

DSutherland

Yes, there could be a memory problem, or a synchronization problem that is showing up in release but not debug. Also, make sure you don't do anything important in any assert blocks. Asserts will not evaluate in Release mode, so there should be no operations in them.

- check for #ifdef _DEBUG or #ifndef _DEBUG. Make sure you're not doing anything vital in a debug-specific block
- check all your assertions (i.e. assert (c) is ok, assert (d=c) is not)

If all else fails, you can use the debugger in release mode:
- Select your Release build configuration.
- Go to Project->Settings->C/C++ Tab->General Category
- Set Debug Info to Program Database
- Go to the Link Tab
- Check Generate Debug Info
- Rebuild

You can now run your release mode through the debugger. Be warned: breakpoints and variables may make absolutely no sense because a lot of the code has been compiled-away or otherwise changed, but it should let you know where your program is crashing.

Edited by - Stoffel on May 10, 2001 2:15:53 PM

It can be a optimization problem. Try to include this:

#pragma optimize("", off)

And test if the release build works.



Zeblar Nagrim, Lord of Chaos

This is at 99% a memory problem.

In debug mode, when you new memory block, VC++ actually allocated huge padding in front and after the memory block and sets everything to 0. This is to help you debug(though it is not the best way to debug memory problem) because you can easely see if you try to assign something to a memory block outside what you should have had allocated.

In release mode, the padding are not there, or much much smaller I believe. So your program craps out.

Happenned to me all the time until I started using Purify.

quote:

---

Original post by Gorg
In debug mode, when you new memory block, VC++ actually allocated huge padding in front and after the memory block and sets everything to 0. This is to help you debug(though it is not the best way to debug memory problem) because you can easely see if you try to assign something to a memory block outside what you should have had allocated.

---

Actually, the default implementation can be found here:
\[devstudio directory]\CRT\SRC\DBGHEAP.C
(CRT = C Runtime Library)
line 318: void * __cdecl _heap_alloc_dbg(...

You should look through this function sometime, step through it on a new. I was going to explain it, but just realized I have class in half an hour, so I''ll summarize:
MSVC does NOT set everything to 0 in debug mode. It sets uninitialized stack memory to 0xCC (just check the value of an uninitialized pointer in a new function), uninitialized heap memory (i.e. with new) to 0xCD, and allocates a no-man''s land before and after the actual memory block that it fills with 0xFD. When it destroys the object, it makes sure that the space before and after the block are still 0xFD; when it''s not, you get the "Damage after/before block X" message.

Release mode doesn''t do anything to the memory you get allocated and it only allocates enough to keep track of how much memory is there (there''s usually a count just before each allocated block in memory that tells how much data''s in that block). Some OSs have the option to zero-pad the memory allocated on the heap, but I don''t know of a standard C way to force that.

Gotta take off. Later.