Destructor-Absturz

Stellen Sie sicher, dass Sie die EXE und die DLL mit derselben Laufzeitumgebung erstellen, vorzugsweise mit der dynamischen Laufzeitumgebung.

Ihr Problem besteht darin, dass unterschiedliche Compiler / Linker-Einstellungen zwischen der EXE- und DLL-Datei bewirken, dass DLL und EXE unterschiedliche Implementierungen der Standardbibliothek verwenden:

• Sie müssen die gleichen Präprozessor-Flags * verwenden, um sowohl die EXE- als auch die DLL-Datei zu erstellen, andernfalls kompiliert jede Binärdatei mit subtil verschiedenen Implementierungen.
• Sie müssen sowohl die EXE-Datei als auch die DLL-Datei mit der dynamischen Laufzeitdatei verknüpfen. Binärdateien, die statisch mit der Runtime verbunden sind, erhalten ihren eigenen Heap - und Sie ordnen sich schließlich auf einem Heap zu und versuchen, auf einem anderen Heap freizugeben.

Um dies zu beheben, gehen Sie zu Project > Properties > Configuration Properties > C/C++ > Code Generation und ändern Sie die Option der Laufzeitbibliothek in Multi-threaded Debug DLL (/MDd) . Sie müssen dies für das EXE-Projekt und das DLL-Projekt tun.

Ab Visual Studio 2010 werden einige dieser Fehler zum Zeitpunkt der Linkverknüpfung mithilfe von #pragma erkannt detect_mismatch .

* _{Für alle Präprozessor-Flags, die Auswirkungen auf die Implementierung der Standardbibliothek haben}

Es stürzt im Destruktor ab, eine Ausnahme wird vom Destruktor ausgelöst, der callt und die Anwendung abstürzt. Uncaught Ausnahmen

  

Es gibt zwei Situationen, in denen ein Destruktor aufgerufen wird. Die erste ist, wenn ein Objekt unter "normalen" Bedingungen zerstört wird, z. B. wenn es außerhalb des Geltungsbereichs liegt oder explizit gelöscht wird. Die zweite ist, wenn ein Objekt durch den Ausnahmebehandlungsmechanismus während des Stapelabwicklungsabschnitts der Ausnahmeausbreitung zerstört wird. Sie müssen Ihre Destruktoren unter der konservativen Annahme schreiben, dass eine Ausnahme aktiv ist. Wenn die Steuerung aufgrund einer Ausnahme einen Destruktor zurücklässt, während eine andere Ausnahme aktiv ist, ruft C ++ die Terminierungsfunktion

auf

Globale Objekte werden von der C-Laufzeit initialisiert und zerstört. Sie werden initialisiert, bevor main aufgerufen und gelöscht wird, nachdem sie zurückgegeben wurde.

Der Fehler wird wahrscheinlich von etwas verursacht, auf das von Ihrem TestClass destructor zugegriffen wird (oder indirekt von einem Source destructor). Der Destruktorcode greift auf ungültigen Speicher zu (oder Speicher, der bereits freigegeben wurde).

Die Reihenfolge der Initialisierung und Zerstörung globaler Variablen ist nicht definiert und ist häufig eine Quelle für Fehler beim Beenden der Anwendung. Wenn es andere Globals gibt, die Ressourcen bereinigen oder ändern können, auf die von TestClass verwiesen wird, könnte dies der Übeltäter sein.

Werden die DLL und die EXE mit derselben Ausrichtung erstellt (pack-Pragma)?

Versuchen Sie, Ihren Konstruktor und Destruktor nicht-inline zu machen. Wenn ctor und dtor nicht inline sind, werden beide im Auftrag von dll erzeugt, so dass Aufbau und Zerstörung der Liste & lt; & gt; wird mit derselben Laufzeitbibliothek ausgeführt. Versuchen Sie im Allgemeinen, undurchsichtige STL-Objekte über DLL-Grenzen hinweg zu passieren. Es ist besser, sie als private Mitglieder in Ihre eigenen Klassen einzubetten und nichtlineare Methoden zur Verfügung zu stellen, um solche Mitglieder zu manipulieren