Boost verursacht einen ungültigen Block beim Überladen neuer/löscht Operatoren

Question

Ich habe ein Problem, das zu einem ungültigen Speicherblock erscheint, der während eines Boost-Anrufs an Boost:runtime:cla::parser::~parser auftritt. Wenn das globale Lösch für dieses Objekt aufgerufen wird, C++ behauptet auf dem Speicherblock als ein ungültiger:

dbgdel.cpp(52): 

/* verify block type */ 
_ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)); 

Eine Untersuchung ergab, ich habe, dass das Problem aufgrund einer globalen Überlastung des neuen passiert/löschen Operatoren. Diese Überladungen werden in einer separaten DLL platziert. Ich entdeckte, dass das Problem nur auftritt, wenn diese DLL in RELEASE kompiliert wird, während die Hauptanwendung in DEBUG kompiliert wird.

Also dachte ich, dass die Release/Debug Build Flavors möglicherweise ein Problem wie dieses in Boost/CRT beim Überladen neuer/löschender Operatoren verursacht haben. Also habe ich versucht, _malloc_dbg und _free_dbg explizit mit den Überladungsfunktionen auch im Freigabemodus aufzurufen, aber das ungültige Heapblockproblem wurde nicht gelöst.

Eine Idee, was die Ursache des Problems ist? Ist diese Situation lösbar?

Ich sollte betonen, dass das Problem erst begann, als ich begann, Boost zu verwenden. Zuvor hat CRT sich nie über einen ungültigen Speicherblock beschwert. Könnte es also ein interner Boost Bug sein?

Danke!

Answer 1

entdeckte ich, dass das Problem nur geschieht, wenn das DLL in RELEASE kompiliert wird, während die Hauptanwendung in DEBUG kompiliert wird

Im Allgemeinen Sie keine Module, die die Freisetzung CRT mit dem Debug-CRT verwenden mischen können, wenn Die Speicherzuweisung von einem Laufzeittyp wird von der anderen Laufzeitumgebung freigegeben (es können andere Probleme auftreten, aber Speicherzuweisungsprobleme scheinen am häufigsten aufzutauchen).

Die Lösung besteht darin, Module zu verwenden, die gegen die Debug-Laufzeit miteinander erstellt werden, und Module, die gegen die Release-Laufzeit miteinander gebaut werden - mischen Sie die beiden nicht.

Erklärung von Microsoft finden Sie hier: http://msdn.microsoft.com/en-us/library/ms235460.aspx

weil jede Kopie der CRT-Bibliothek einen eigenen Heap-Manager hat, Gedächtnis und vorbei über eine DLL-Grenze den Zeiger in einer CRT-Bibliothek Zuweisen von einem befreit werden Eine andere Kopie der CRT-Bibliothek ist eine mögliche Ursache für Heap-Beschädigung.