The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Problems with Release build (but not Debug)

My app works fine in the Debug build, but can barely load in Release mode. In fact, the GUI ends up all stuffed up in Release mode and takes about 4 minutes to load. Any advice? BTW, I install BoundsCheckers as I thought it would help, but it really did not find that many errors in my code.

Wednesday, March 30, 2005
Difference between release and debug come almost exclussively from one of two sources:

1. Optimiser bugs. Try turning optimisations settings down and see if it helps.

2. Uninitialised variables. Debug builds tend to do some auto-intialisation of variables, which is absent from release builds.

It does vary a great deal between compilers though. What are you using?
Mr Jack
Wednesday, March 30, 2005
Also, printfs and other debug calls can alter the stack such that things that shouldn't work actually work in debug builds. You can try the debug build and transform into a release build one step at a time to see what the deal is.
son of parnas
Wednesday, March 30, 2005
My experience with this type of issue has shown that the problem is usually a pointer issue. The release build has a different memory footprint which causes "good" memory on the heap to be overwritten. In debug mode, the bad pointer ends up ovewriting a different area of memory that doesn't cause the problem to typically be seen.

What is tough about theis type of situation is that the pointer problem could have been in there for years and is only being seen now because you added more objects to the heap. Another sign of this problem is that when you try to add printf and other types of debug methods to the release build the problem goes away. This is because the extra code/variables added ends up pushing the problem into unused heap space causing it to disapear.

Just my personal experience.
Wednesday, March 30, 2005
You might want to check the stack. We had one bug at a prior company where the debug stack was different from the release stack, which caused destructors to be fired in the wrong sequence, causing a crash.

Naturally, it only happened in release mode...
Wednesday, March 30, 2005
Another vote here for uninitialized memory.

Debug modes usually set variables to some magic number that the compiler uses for "this memory is uninitialized."
Wednesday, March 30, 2005
Maybe the advice is too late for the occasion, but I prefer to regularly compile and test the release version, even though working in debug mode. That avoids this kind of surprise.
Also look for funny #ifdef's.
Else you might have to resort to plain old printf() debugging.
Wednesday, March 30, 2005
Also, look for code in ASSERT statements.
Dumb, but I've seen it happen!!
Wednesday, March 30, 2005
Perhaps mixed objects of debug and release types

Perhaps the MSVC incremental linker (we call it the excremental linker)

Perhaps you have linked to a debug DLL from a release DLL and the runtime being used between them doesn't then allow you to share objects the right way

getting back to things others have mentioned
unmatched blocks spanning #ifdef's - if your compiler supports it, it is better to use boolean constant optomisation to remove sections of code.  define a constant isDebug = 1 in debug and = 0 in release.  use it similarly to #ifdef except with appropriatly tested and unchanging blocks in the program.  the compiler will take if( isDebug ) and remove the block if it is 0.
gorf Send private email
Friday, April 01, 2005
Consider not using a 'release' build:
* Optimizations are rarely worth doing (especially if it's spending most of its time inside the library and O/S APIs instead of inside your code)
* Agressive optimizations make it nearly impossible to debug any crash dump you might get from a customer site (optimizes away the debugger's ability to walk up the call the stack)
* If developers should release what they test, and they test what they use, and if they're using debug builds, then debug builds are what they should be releasing
Christopher Wells Send private email
Friday, April 08, 2005
> install BoundsCheckers as I thought it would help,
> but it really did not find that many errors in my
> code.

To make a program crash you only need one error!
Jussi Jumppanen
Monday, April 11, 2005

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz