Freigeben über

Beheben bekannter Probleme und Einschränkungen

Hinweis

Senden Sie uns Feedback dazu, was Sie in zukünftigen Versionen sehen möchten, und melden Sie Fehler , wenn Probleme auftreten.

Inkompatible Optionen und Funktionen

Die folgenden Optionen und Funktionen sind nicht kompatibel mit /fsanitize=address und sollten deaktiviert oder vermieden werden.

Standardbibliotheksunterstützung

Die Microsoft Visual C++ (MSVC)-Standardbibliothek (STL) verwendet die AddressSanitizer teilweise und stellt weitere Codesicherheitsprüfungen bereit. Weitere Informationen finden Sie unter container-overflow "Fehler".

Wenn Anmerkungen deaktiviert sind oder in Versionen der Standardbibliothek, die sie nicht unterstützen, identifizieren AddressSanitizer-Ausnahmen, die im STL-Code ausgelöst werden, weiterhin echte Fehler. Sie sind jedoch präziser, wenn Anmerkungen aktiviert sind und Sie eine Version der Standardbibliothek verwenden, die sie unterstützt.

In diesem Beispiel wird das Fehlen von Genauigkeit und die Vorteile der Aktivierung von Anmerkungen veranschaulicht:

// Compile with: cl /fsanitize=address /Zi
#include <vector>

int main()
{   
    // Create a vector of size 10, but with a capacity of 20.    
    std::vector<int> v(10);
    v.reserve(20);

    // In versions prior to 17.2, MSVC ASan does NOT raise an exception here.
    // While this is an out-of-bounds write to 'v', MSVC ASan
    // ensures the write is within the heap allocation size (20).
    // With 17.2 and later, MSVC ASan will raise a 'container-overflow' exception:
    // ==18364==ERROR: AddressSanitizer: container-overflow on address 0x1263cb8a0048 at pc 0x7ff6466411ab bp 0x005cf81ef7b0 sp 0x005cf81ef7b8
    v[10] = 1;

    // Regardless of version, MSVC ASan DOES raise an exception here, as this write
    // is out of bounds from the heap allocation.
    v[20] = 1;
}

Außerkraftsetzung operator new und delete

AddressSanitizer (ASan) verwendet eine benutzerdefinierte Version von operator new und operator delete um Zuordnungsfehler wie alloc_dealloc_mismatch. Führen Sie den Linker aus/INFERASANLIBS, um sicherzustellen, dass die Außerkraftsetzung von new/deleteASan eine niedrigere Priorität hat, sodass der Linker in anderen Bibliotheken über die benutzerdefinierten Versionen von ASan entscheidet operator new oder operator delete überschreibt. In diesem Fall kann ASan einige Fehler nicht abfangen, die auf ihren benutzerdefinierten und operator new.operator delete

MFC enthält benutzerdefinierte Außerkraftsetzungen für operator new und operator delete. Wenn Microsoft Foundation Classes (MFC) außer den bereitgestellten operator new ASan-Außerkraftsetzungen verwendet werden und operator deleteASan fehler möglicherweise vollständig fehlt oder sie als Ergebnis falsch klassifizieren. Die folgenden Fehler können verpasst oder falsch klassifiziert werden:

Speicherauslastung

Die AddressSanitizer-Laufzeit gibt arbeitsspeicher während der Ausführung nicht wieder auf das Betriebssystem zurück, sodass der Arbeitsspeicher nicht alle vorab zugeordnet ist. Aus Sicht des Betriebssystems sieht es möglicherweise so aus, als ob es einen Speicherverlust gibt.

AddressSanitizer-Laufzeit-DLL-Speicherorte

Die clang_rt.asan*.dll Laufzeitdateien werden neben den Compilern in %VSINSTALLDIR%\VC\Tools\MSVC\<version>\bin\<host-arch>\<target-arch>\installiert. Diese Speicherorte befinden sich im Pfad in Debugsitzungen und in Visual Studio-Entwickler-Eingabeaufforderungen. Diese Dateien werden niemals in C:\Windows\System32 oder C:\Windows\SysWOW64.

Unterstützung für benutzerdefinierte Eigenschaftenblätter

Mit dem Visual Studio Property Manager-Fenster können Sie Ihren Projekten benutzerdefinierte .props Dateien hinzufügen. Obwohl die Enable AddressSanitizer-Eigenschaft (<EnableASAN>) angezeigt wird, berücksichtigt der Build ihn nicht. Der Build berücksichtigt sie nicht, da die benutzerdefinierten .props Dateien enthalten Microsoft.cpp.propssind, die den <EnableASAN> Wert zum Festlegen anderer Eigenschaften verwenden.

Erstellen Sie als Problemumgehung eine Directory.Build.props Datei im Stammverzeichnis Ihres Projekts, um die <EnableASAN> Eigenschaft zu definieren. Weitere Informationen finden Sie unter Anpassen von C++-Builds.

Lokale Threadvariablen

Lokale Threadvariablen (globale Variablen, die mit __declspec(thread) oder thread_local) deklariert wurden, sind nicht durch AddressSanitizer geschützt. Diese Einschränkung ist nicht spezifisch für Windows oder Microsoft Visual C++, sondern eine allgemeine Einschränkung.

Benutzerdefinierter Code überspringt die rückgabesequenz der normalen Funktion.

Die Verwendung von benutzerdefiniertem Code oder der Assemblysprache, um den aktuellen Stapelframe zu verlassen, ohne die üblichen Rückgabemechanismen zu berücksichtigen, wird nicht unterstützt. Beispielsweise kann das Verlassen des aktuellen Stapelrahmens über einen langen Sprung falsche positive Ergebnisse erzeugen.

Rufen Sie stattdessen vor dem Aufrufen von benutzerdefiniertem langsprungähnlichem Code auf __asan_handle_no_return() . Diese Funktion löscht alle Schattenbytes, die dem Stapel des aktuellen Threads zugeordnet sind, was zu einer verlorenen Abdeckung führt und das Risiko falsch negativer Negativer einführt. Aber Ihr Programm kann den Stapel dann sicher entspannen, ohne aufgrund veralteter Stapelschattenbytes falsch positiv zu laufen.

Probleme mit teilweise sanierten ausführbaren Dateien

Wenn der gesamte Code in einem Prozess nicht kompiliert /fsanitize=addresswird, kann ASan möglicherweise nicht alle Speichersicherheitsfehler diagnostizieren. Das häufigste Beispiel ist, wenn eine mit ASan kompilierte DLL in einen Prozess geladen wird, der Code enthält, der nicht mit ASan kompiliert wurde. In diesem Fall versucht ASan, Zuordnungen zu kategorisieren, die vor der ASan-Initialisierung stattgefunden haben. Sobald diese Zuordnungen neu zugewiesen wurden, versucht ASan, die Lebensdauer des Speichers zu besitzen und zu überwachen.

Wenn alle mit ASan kompilierten DLLs aus dem Prozess entladen werden, bevor der Prozess beendet wird, kann es zu Abstürzen kommen, da Verweise auf abgefangene Funktionen wie memcmp, memcpy, memmoveusw. abgefangen werden. Um optimale Ergebnisse zu erzielen, kompilieren Sie alle Module, die getestet /fsanitize=addresswerden, oder entladen Sie module nicht, die nach der Eingabe des Prozesses mit ASan kompiliert wurden.

Melden Sie alle Fehler an unserer Entwicklercommunity.

ASan 64-Bit–Ausnahmen für die erste Chance

Auf x64 belegt der Schattenbytebereich von MSVC ASan mehrere Terabyte des virtuellen Adressraums. ASan stellt diesen Speicher nicht vorab fest. Stattdessen wird on-Demand-Paging verwendet. Wenn zum ersten Mal auf eine Schattenseite zugegriffen wird, tritt eine Ausnahme des Fehlers der ersten Chance auf Seiten auf und wird von ASan behandelt, wodurch die Seite ausgeführt wird.

Der Visual Studio-Debugger behandelt dies ordnungsgemäß und zeigt diese Ablaufverfolgungen nicht an. Debugger wie WinDbgX können jedoch standardmäßig für jede Ausnahme unterbrechungen. Das Deaktivieren von Unterbrechungen bei Ausnahmen mit der ersten Chance wird empfohlen. In WinDbgX entspricht dies beispielsweise dem sxd av Befehl.

Siehe auch

AddressSanitizer -Übersicht
AddressSanitizer Build- und Sprachreferenz
AddressSanitizer-Laufzeitreferenz
AddressSanitizer-Schattenbytes
AddressSanitizer-Cloud oder verteilte Tests
AddressSanitizer Debugger-Integration
Beispiele für AddressSanitizer-Fehler

  • Last updated on