C ++ - Fehler bei Ms Visual Studio: "Windows hat einen Unterbrechungspunkt in javaw.exe ausgelöst"
Ich habe immer an meiner Software C ++ & amp; Java (Build mit Microsoft Visual Studio 2008 und Eclipse), und ich habe versucht, es von einem 32-Bit-System zu einem 64-Bit-System zu verschieben.
Die Kompilierungsphase ist in Ordnung, aber bei der Ausführung bekomme ich einen Fehler, der besagt:
"Windows hat in javaw.exe einen Haltepunkt ausgelöst. Dies kann auf sein Beschädigung des Heapspeichers, die auf einen Fehler in javaw.exe oder einem der folgenden Fehler hinweist die DLLs, die es geladen hat. Dies kann auch daran liegen, dass der Benutzer F12 drückt, während javaw.exe den Fokus hat. Das Ausgabefenster kann mehr Diagnoseinformationen enthalten. [BREAK] [WEITER] [IGNORE] "
Sie können hier eine Momentaufnahme des Fehlers sehen:
Haben Sie eine Vorstellung davon, was dieser Fehler bedeutet? Was bedeutet "Korruption des Heaps"? Haben Sie schon einmal Erfahrungen mit dieser Art von Fehlern gemacht?
Vielen Dank!
4 Antworten
Es ist eine sehr nette Eigenschaft des Windows-Heap-Allokators, der seit Vista verfügbar ist. Es sagt Ihnen, dass Ihr Code einen Zeigerfehler hat. Nun, hoffentlich ist es Ihr Code und nicht die JVM, die den Fehler hat :) Sie sollten besser annehmen, dass es Ihr Code ist.
Die eigentliche Ursache liegt irgendwo zwischen mild, wie der Versuch, Speicher zu befreien, der bereits freigegeben oder von einem anderen Heap zugewiesen wurde (nicht ungewöhnlich, wenn Sie mit einem anderen Programm interpieren), zu drastisch unangenehm, wie den Haufen in Stücke früher durch Überlaufen geblasen ein Heap reservierter Puffer.
Die Diagnose ist nicht feinkörnig genug, um Ihnen genau zu sagen, was schief gelaufen ist, nur dass etwas nicht stimmt. Sie verfolgen es normalerweise mit einer sorgfältigen Codeüberprüfung und deaktivieren künstlich Codeabschnitte, bis der Fehler verschwindet. Das sind die Freuden des expliziten Speichermanagements. Wenn die 32-Bit-Version sauber ist (überprüfen), kann dies aufgrund von Annahmen über die Zeigergröße mit 64-Bit-Code verknüpft werden. Ein 64-Bit-Zeiger passt nicht in einen Int oder Long, also wird er abgeschnitten. Und die Verwendung des abgeschnittenen Zeigerwerts wird diese Assertion auslösen. Das ist die glückliche Art von Problem, Sie finden den Fehlercode wieder im Call Stack-Fenster.
Dies bedeutet leider normalerweise eine Speicherbeschädigung. Einige doppelte Speicherbefreiung, Funktion, die zurückkehren sollte, aber keine oder andere Art von undefiniertem Verhalten.
Wenn Sie keine Ahnung haben, wo diese Korruption liegt, sollten Sie dies am besten mit einem Speicheranalyse-Tool lösen.
Ich habe es! Dank euch allen, ich habe verstanden, dass es ein Problem der Erinnerung war, und vielleicht von malloc () Tatsächlich lese ich hier :
Der Bucket-Sizing-Faktor muss bei 32-Bit-Implementierungen ein Vielfaches von 8 sein ein Vielfaches von 16 für 64-Bit-Implementierungen, um diese Adressen zu garantieren zurückgegeben von malloc subsystem Funktionen sind ordnungsgemäß für alle Datentypen ausgerichtet.
IBM.com :
Also habe ich die Größe von malloc () im Problempunkt geändert. Ich ging von:
(int **) malloc (const * sizeof (int))
zu:
(int **) malloc (const * sizeof (int64_t))
Und jetzt funktioniert es!
Vielen Dank!
Diese Art von Fehlern tritt normalerweise auf, wenn Sie versuchen, auf den Speicher zuzugreifen, den Sie nicht zugewiesen haben. Überprüfen Sie all Ihre Zuweisungen (und Freigeben), insbesondere Zeiger auf Zeiger, und Code, der auf dynamisch zugewiesenen Speicher zugreifen kann. In Ihrem Fall ist die Größe der Pointen 64bit indedead 32bit, das sollte Hauptursache sein.
Tags und Links c++ visual-studio-2008