CODEWITHSUNDEEP
c++destructor
bjskishore123
bjskishore123

Reputation: 6352

Destructor crash

I am working on a Win32 c++ application in Visual studio.

In one of the source files, I have global object like below.

TestClass tObj;

int main() //Execution starts here
{
}

TestClass is defined in other DLL like below.

struct Source
{

};

class TestClass
{
  list<Source> sourceList;
    public:
         TestClass() {}
        ~TestClass() {}
};

While my application is running, if i try to close the app explicitly, by closing the console window, it is crashing in TestClass destructor. Callstack shows CrtIsValidHeapPointer is failing.

Pls help me to solve this issue.

Upvotes: 8

Views: 2910

Answers (6)

JoeG
JoeG

Reputation: 13192

Your problem is that differing compiler/linker settings between the .exe and .dll are effectively causing the .dll and .exe to be using different implementations of the standard library:

  • You must use the same preprocessor flags* to build both the .exe and the .dll, otherwise each binary will compile with subtly different implementations.
  • You must link both both the .exe and the .dll to the dynamic runtime. Binaries linked statically to the runtime get their own heap - and you end up allocating on one heap and trying to free on another.

To fix this, go to Project > Properties > Configuration Properties > C/C++ > Code Generation and change the runtime library option to Multi-threaded Debug DLL (/MDd). You must do this for both the .exe project and the .dll project.

As of Visual Studio 2010, some of these kind of errors will be detected at link time using #pragma detect_mismatch.

*For all preprocessor flags that have any effect of the standard library implementation

Upvotes: 9

user396672
user396672

Reputation: 3166

try to make your constructor and destructor non-inline, it may help. If ctor and dtor are not inline, both will be generated on behalf of dll, so construction and destruction of list<> will be executed with the same runtime library. Generally, try to avoid passing opaque stl objcts across dll boundaries. It is better to incapsulate them as privatte members into your own classes and provide non-inlined methods to manipulate such a members

Upvotes: 0

Chubsdad
Chubsdad

Reputation: 25547

Are the DLL and the EXE built using the same alignment (pack pragma)?

Upvotes: 0

sbi
sbi

Reputation: 224199

Make sure you build bot the EXE and the DLL with the same runtime, preferably with the dynamic runtime.

Upvotes: 4

Seb Rose
Seb Rose

Reputation: 3666

Global objects are initialised and destroyed by the C runtime. They are initialised before main is called and destroyed after it returns.

The error is probably caused by something that is being accessed from your TestClass destructor (or indirectly from a Source destructor). The destructor code is accessing invalid memory (or memory that has already been freed).

The order of initialisation and destruction of global variables is not defined, and is frequently a source of errors on application termination. If there are other globals that might clean up or modify resources referenced by TestClass, then this could be the culprit.

Upvotes: 1

DumbCoder
DumbCoder

Reputation: 5766

It is crashing in the destructor, an exception is being thrown from the destructor which is calling terminate and crashing your application.Uncaught exceptions

There are two situations in which a destructor is called. The first is when an object is destroyed under "normal" conditions, e.g., when it goes out of scope or is explicitly deleted. The second is when an object is destroyed by the exception-handling mechanism during the stack-unwinding part of exception propagation. You must write your destructors under the conservative assumption that an exception is active, because if control leaves a destructor due to an exception while another exception is active, C++ calls the terminate function

Upvotes: 1

Related Questions