CODEWITHSUNDEEP
c++visual-c++gcccrash
John Doe III
John Doe III

Reputation: 13

C++ Program freezes esoterically

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?

Upvotes: 1

Views: 3132

Answers (3)

John Doe III
John Doe III

Reputation: 13

Thank you all, especially Cody Gray and MikMik, I found it! As some of you recommended I told VS to generate debug information and disabled optimizations in the release configuration. Then I started the program and paused it. Alternatively I remotely attached to the running process. This helped me finding the region where the error was. The reasons were infinite loops, caused by reads behind the boundaries of an array and a missing exclusion of an invalid case. Both led to unreachable stopping conditions at runtime. The esoteric part came from the fact, that my program uses some randomized values. That's life...

Upvotes: 0

Jan Hudec
Jan Hudec

Reputation: 76306

  • 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).

Upvotes: 1

wrock
wrock

Reputation: 1349

Debug versions usually initialize all allocated memory (MSVC fills them with 0xCD with the debug configuration). Maybe you have some uninitialized values in your classes, with the GCC configurations and MSVC Debug configuration it gets a "lucky" value, but in MSVC Release it doesn't.

Here are the rest of the magic numbers used by MSVC.

So look for uninitialized variables, attributes and allocated memory blocks.

Upvotes: 1

Related Questions