Destructor crash

Question

Estoy trabajando en una aplicación Win32 C++ en Visual Studio.

En uno de los archivos fuente, tengo un objeto global como el siguiente.

TestClass tObj; 

int main() //Execution starts here 
{ 
} 

TestClass se define en otra DLL como la de continuación.

struct Source 
{ 

}; 

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

Mientras que mi aplicación se está ejecutando, si trato de cerrar la aplicación explícita, cerrando la ventana de la consola, que está fallando en TestClass destructor. Callstack muestra que CrtIsValidHeapPointer está fallando.

Pls me ayudan a resolver este problema.

Answer 1

Asegúrese de compilar el EXE y la DLL con el mismo tiempo de ejecución, preferiblemente con el tiempo de ejecución dinámico.

Answer 2

Se está cayendo en el destructor, se está produciendo una excepción desde el destructor que llama a terminar y bloquear su aplicación. Uncaught exceptions

Hay dos situaciones en las que se llama a un destructor. El primero es cuando un objeto se destruye bajo condiciones "normales", por ejemplo, cuando sale del alcance o se elimina explícitamente. El segundo es cuando un objeto es destruido por el mecanismo de manejo de excepciones durante la parte de desenrollado de la propagación de la excepción. Debe escribir sus destructores bajo el supuesto conservador de que una excepción es activo, ya que si el control deja un destructor debido a una excepción, mientras que otra excepción es activa, C++ llama a la función terminan

Answer 3

objetos globales se inicializan y destruidos por la C tiempo de ejecución. Se inicializan antes de que se llame main y se destruya después de que regrese.

El error probablemente sea causado por algo a lo que se accede desde su destructor TestClass (o indirectamente desde un destructor Source). El código de destructor está accediendo a la memoria no válida (o memoria que ya se ha liberado).

El orden de inicialización y destrucción de las variables globales no está definido, y con frecuencia es una fuente de errores en la finalización de la aplicación. Si hay otros elementos globales que podrían limpiar o modificar recursos a los que hace referencia TestClass, este podría ser el culpable.

Answer 4

¿Están el DLL y el EXE construidos usando la misma alineación (paquete pragma)?

Answer 5

Su problema es que las diferentes configuraciones de compilador/enlazador entre el .exe y .dll están causando efectivamente los archivos .dll y .exe sea utilizando diferentes implementaciones de la biblioteca estándar:

• debe utilizar la misma indicadores de preprocesador * para compilar tanto .exe como .dll; de lo contrario, cada binario compilará con implementaciones sutilmente diferentes.
• Debe vincular tanto el .exe como el .dll al tiempo de ejecución dinámico. Los binarios vinculados de forma estática con el tiempo de ejecución obtienen su propio montón, y terminas asignando en un montón e intentando liberar en otro.

Para solucionar este problema, vaya a Project > Properties > Configuration Properties > C/C++ > Code Generation y cambie la opción de biblioteca de tiempo de ejecución para Multi-threaded Debug DLL (/MDd). Debe hacer esto tanto para el proyecto .exe como para el proyecto .dll.

A partir de Visual Studio 2010, algunos de estos tipos de errores se detectarán en el momento del enlace utilizando #pragma detect_mismatch.

* _{Para todas las banderas del preprocesador que tienen algún efecto de la implementación de la biblioteca estándar}

Answer 6

tratar de hacer su constructor y el destructor no en línea, que pueden ayudar. Si ctor y dtor no están en línea, ambos se generarán en nombre de dll, por lo que la construcción y destrucción de la lista <> se ejecutará con la misma biblioteca de tiempo de ejecución. Generalmente, trate de evitar pasar objetos stl opacos a través de los límites dll. Es mejor encapsularlos como miembros de privatte en sus propias clases y proporcionar métodos no alineados para manipular dichos miembros.