views:

276

answers:

2

I have a VS 2005 C++ project with both Debug and Release builds. I've attempted the following 4 things:

  1. Build a Debug executable through Visual Studio, and run it through Visual Studio.
  2. Run the executable built in (1) externally via command line (Cygwin) after cd'ing to vstudio/debug.
  3. Build a Release executable through Visual Studio, and run it through Visual Studio.
  4. Run the executable built in (3) externally via command line (Cygwin) after cd'ing to vstudio/release.

The first 3 all succeed: the program runs to completion.

The fourth, however, crashes at runtime. Debugging shows that the culprit is the call to malloc() inside the operator new(). The relevant context looks something like this:

template<typename T> class Foo {
    ...
    static void bar() {
        ...
        T* ptr = new T();
        ...
    }
    ...
}

If anyone can think of any problem which would lead to the 3-out-of-4 symptoms I describe, it would be much appreciated.

+1  A: 

You probably have a corrupt heap. This can be caused by a pointer writing outside the allocated memory.

A possible reason why this does not happen in debug mode is that you only overwrite debug information on the heap (which is not present in release mode).

I don't know you environment but you should probably get a tool like BoundsChecker to find the bug.

chris
Quite likely. The OS uses a different heap when programs run under the debugger. Check with AppVerifier.
MSalters
The heap corruption hypothesis seems likely.Before I look into some of these other tools, though, do you have a hypothesis for why it would work for (3) but not (4)?
for (3) - when you say 'run' from VS do you mean launching or debugging?
chris
I mean debugging.
In that case it doesn't surprise me too much. I encountered similar bugs that would not show up while debugging (the debugger affects the debugged app). One of those was caused by the compiler itself and fixed by a 'rebuild all'. It probably won't help in your case but I'd give it a try.
chris
Indeed, it is a heap corruption problem. Thanks for your help!
A: 

My first guess would be that cygwin has replacement DLL's for some of the Windows DLL's that your program was built to use.

A good way to test this would be to try running under the Windows command shell (cmd.exe) and see if you get the same error.

T.E.D.
I attempted running under Windows command shell. I got the same error, although strangely, it was not at the exact same spot as when I launched with cygwin. It was the same templatized call `Foo<T>::bar()`, although with a different `T`.
In that case, I think I'm with Chris.
T.E.D.