Im unten gezeigten Code habe ich alle dokumentierten Möglichkeiten verwendet, um eine Ausnahme zu erkennen und eine Diagnose zu erstellen. Es verwendet die C ++ - try / catch-Schlüsselwörter, fängt eine SEH-Ausnahme mit den Erweiterungsschlüsseln __try/__catch ab, verwendet die WinVA-Funktionen AddVectoredExceptionHandler () und SetUnhandledExceptionFilter () von WINAPI, um VEH / SEH-Filter zu installieren.
Ausführen mit Visual C ++ 2003:
/ GS: gibt "Hallo, Welt!" Aus und endet mit Exit-Code 0.
/ GS-: gibt "Hallo, Welt!" Aus und endet mit dem Exit-Code 0.
Dies mit Visual C ++ 2013 ausführen:
/ GS: keine Ausgabe, endet mit Exit-Code -1073740791
/ GS-: gibt "Hallo, Welt!" Aus und endet mit dem Ausgang mit 0.
Wie erstelle ich eine Diagnose in einem VS2013 kompilierten Programm mit / GS in Kraft?
%Vor% Die CRT-Funktion, die die Erkennung von Stack-Pufferüberläufen behandelt, __report_gsfailure() , geht davon aus, dass die Beschädigung des Stack-Frames durch einen Malware-Angriff ausgelöst wurde. Eine solche Malware ist traditionell mit den fs: [0] SEH-Ausnahmefiltern (im Stack-Frame gespeichert) verwechselt worden, um einen Exception-Handler zum Auslösen der Malware-Payload zu erhalten. Eine Möglichkeit, Daten in ausführbaren Code umzuwandeln.
Damit kann die CRT-Funktion nicht davon ausgehen, dass das Auslösen einer Ausnahme sicher ist. Und nicht mehr in der CRT mit VS2013, geht zurück zu ~ VS2005. Es wird failfast, wenn das Betriebssystem es unterstützt, und wenn nicht, wird sichergestellt, dass ein registrierter VEH / SEH-Ausnahmebehandler die Ausnahme auch nicht sehen kann. Kaboom, crash auf den Desktop ohne Diagnose, es sei denn, Sie haben einen Debugger angeschlossen.
Die Option / SAFESEH vereitelt diese Art von Malware-Angriffen und ist daher nicht so ernst wie früher. Wenn Sie sich noch in der Phase befinden, in der Ihr Code unter Stack-Korruptions-Bugs leidet und Ihre App nicht populär genug ist, um zum Ziel von Malware zu werden, dann sollten Sie die CRT-Funktion ersetzen.
Sprechen Sie das mit Ihrem Vorgesetzten ab, Sie wollen angesichts der enormen Verantwortung gegenüber Ihrem Kunden niemals persönlich dafür verantwortlich sein. Die Geschichte erzählt selten die Geschichte von dem, was mit dem einen Programmierer passiert ist, dessen Code einen ganzen Konzern für einen Monat außer Gefecht setzte. Aber sicher war nichts hübsches.
Fügen Sie diesen Code irgendwo in der Nähe Ihrer main () -Funktion ein:
%Vor%Und plane, es bald wieder zu entfernen.
Es gibt keine Lösung für die gestellte Frage.
Das Überfahren eines Arrays führt zu undefiniertem Verhalten in Standard-C ++, sodass kein bestimmtes Ergebnis garantiert ist. Fehler beim Geben eines zuverlässigen Ergebnisses ist kein Problem mit dem Compiler - es ist erlaubtes Verhalten.
Ich kenne keine Implementierung, die ein bestimmtes Verhalten als Reaktion auf einen Überlauf garantiert - VS sicherlich nicht. Was nicht verwunderlich ist, da Compiler dies nicht tun müssen (im Wesentlichen die Bedeutung von undefiniertem Verhalten). Der Grund dafür ist, dass es oft schwierig ist, solche Ereignisse zuverlässig oder konsistent zu erkennen.
Dies bedeutet, dass die einzige konsistente Methode zum Erkennen eines Array-Überlaufs darin besteht, zu überprüfen, ob die Array-Indizes gültig sind, BEVOR sie für den Zugriff auf ein Array-Element verwendet werden und geeignete Maßnahmen ergreifen (z. B. eine Ausnahme auslösen, die abgefangen werden kann). . Der Nachteil ist, dass es keine einfache oder zuverlässige Möglichkeit bietet, Fehler in beliebigem Code zu finden - kurz, um den gesamten Code zu modifizieren, um die erforderlichen Prüfungen durchzuführen.