Question

I wrote a C++ CLI program with MS VC++ 2010 and GCC 4.2.1 (for Mac OS X 10.6 64 bit, in Eclipse).
The program works well under GCC+OS X and most times under Windows. But sometimes it silently freezes. The command line cursor keeps blinking, but the program refuses to continue working.

The following configurations work well:
GCC with ‘Release’ and ‘Debug’ configuration.
VC++ with ‘Debug’ configuration

The error only occurs in the configuration ‘VC++ with ‘Release’ configuration’ under Win 7 32 bit and 64 bit. Unfortunately this is the configuration my customer wants to work with ;-(

I already checked my program high and low and fixed all memory leaks. But this error still occurs. Do you have any ideas how I can find the error?

Answer 1

• Use logging to narrow down which part of code the program is executing when it crashes. Keep adding log until you narrow it down enough to see the issue.
• Enable debug information in the release build (both compiler and linker); many variables won’t show up correctly, but it should at least give you sensible backtrace (unless the freeze is due to stack smashing or stack overflow), which is usually enough if you keep functions short and doing just one thing.
• Memory leaks can’t cause freezes. Other forms of memory misuse are however quite likely to. In my experience overrunning a buffer often cause freezes when that buffer is freed as the free function follows the corrupted block chains. Also watch for any other kind of Undefined Behaviour. There is a lot of it in C/C++ and it usually behaves as you expect in debug and completely randomly when optimized.
• Try building and running the program under DUMA library to check for buffer overruns. Be warned though that:
  • It requires a lot of memory. I mean easily like thousand times more. So you can only test on simple cases.
  • Microsoft headers tend to abuse their internal allocation functions and mismatch e.g. regular malloc and internal __debug_free (or the other way ’round). So might get a few cases that you’ll have to carefully workaround by including those system headers into the duma one before it redefines the functions.
• Try building the program for Linux and run it under Valgrind. That will check more problems in addition to buffer overruns and won’t use that much memory (only twice as normal, but it is slower, approximately 20 times).