Ich bräuchte AddressSanitizer für Windows



  • Kann mir jemand sagen, mit welcher Software oder Methode ich zusammen mit dem Visual C++ Compiler vegleichbare Ergebnisse bekomme wie mit "-fsanitize=address" bei GCC und Clang?

    Ich fand heute z.B. "Dr. Memory". Leider stürzt es ab, ohne dass ich herausfand, was da für eine Exception passiert ist. Ich kann dann mit dem JIT-Debugger von Visual Studio weiter machen, aber der zeigt dann nicht mal ein Modul an, geschweige denn eine stack trace oder einen Namen einer Exception.

    Und das Problem mit MingW und MingW-w64 ist, dass sie mit "-fsanitize=address" nicht linken wollen und sagen, dass sie "-lasan" nicht finden. Also, an diesem Punkt war ich früher schon mal.

    Clang für Windows linkt auch bei Verwendung von "-fsanitize=address", erzeugt aber dann im Falle eines Array-Überschreibens seinerseits eine Exception durch Schreiben an der Adresse Null. Das passt nicht zu dem Zweizeiler, mit dem ich es gestestet habe (dieser schreibt definitiv nicht an Adresse Null), womit das also ein Problem mit Clang selbst zu sein scheint.

    Bei MingW und Clang für Windows besteht zusätzlich das Problem, dass die Implementation von <thread> nicht genau das tut, was sie soll. join() verhält sich anders (und löst damit Fehlverhalten aus) als bei <thread> von Microsoft, und das ist ein weiteres Hemmnis, überhaupt damit zu arbeiten.

    Also habe ich heute mal WinDbg und Application Verifier benutzt und bekam dann aber nur Adressen ohne Symbole zu einem "contains an active SRW lock". Kann das WinDbg 7.1 vielleicht das evtl. neuere Format der Debugging-Symbole aus Visual C++ 2015 nicht? Ich muss wohl ein neueres WinDbg finden, die neue Windows 10 SDK, aber ich kann nicht auf Windows 10 migrieren, geht einfach nicht, weil 10 nicht die Zielplatform ist. Was von der neuesten SDK auf Windows 7 läuft, wollte ich heute nicht herausfinden.

    Es bieten sich ein paar kommerzielle Lösungen an. Aber eine Trial gibt es nur von Borland, für 7 Tage. Und der Preis ist für mich abschreckend.

    Von cl.exe habe ich /GS und /RTCsu probiert, aber fand damit keinen Bug - vielleicht weil es sich um eine globale Variable handelt.

    Ohne eine brauchbare Lösung muss ich meine Fehler "auf dem Papier" suchen, oder in Linux, obwohl die Zielplatform Windows ist - also fast unmöglich.



  • Kleiner Nachtrag zu "Dr. Memory": Natürlich hätte ich die Chance gehabt im Crash-Report von Windows den Namen der Exception herauszufinden - sorry. Und inzwischen - nach Deinstallation von Application Verifier - verabschiedet sich Dr. Memory anders, nämlich mit der Bitte, irgendwelche invasive Software zu beenden, die ihn stören würde.

    Aber ob dieses Tool überhaupt die gleichen Fähigkeiten wie AddressSanitizer haben kann? Es erkennt Zugriffe auf "unaddressable memory" und nutzt "unmodified application binaries". AddressSanitizer fügt zur Binary aber paddings hinzu, d.h. eigentlich will ich nicht wirklich Dr. Memory, weil es nicht wissen kann, ob da bugs vom Typ IntraObjectOverflow geschehen.

    Anderereseits kann ich mit C++ so viel Sch... bauen, die AdressSanitizer nicht erkennen könnte, dass ich mir die Frage stellen sollte, ob ich nicht einfach allumfänglich selbst schuld bin und ohne Tool auskommen und solange allgemein meinen C++-Queltext verbessern sollte bis versteckte Bugs unabhängig von den Symptomen gefixt werden.



  • Meine Methode wird wohl die sein: JIT-Debugging (ohne VS IDE arbeiten etc.) vergessen, diese Klickibuntu VS IDE installieren, dann selber padden und mit Breakpoint überwachen, wann der unbefugte Schreibzugriff erfolgt.

    Unter Windows muss man sich dieser bunten, überfrachteten, hässlichen IDE einfach stellen. Das Ding knallt mir gleich dutzende Dateien und Ordner in mein hübsches Projekt und bietet mir Zeugs an, das kein Mensch braucht. 😞



  • Bevor sich jemand wegen meines Threads den Kopf zerbricht, ich hatte einen Fehler im Quelltext bezüglich Reihenfolge von Destruktoren von globalen Variablen. AddressSanitizer hätte mir nicht geholfen, bzw. es hätte nur bestätigt, dass kein IntraObjectOverflow vorliegt. Ob man in letzter Konsequenz etwas wie die Sprache Rust braucht, ist ja allein schon durch dessen Existenz beantwortet. Aber ich benutze jetzt halt wegen bestimmer Libraries C++, also werd ich einfach nicht weiter drüber nachdenken. 😡 😃



  • Wer benutzt denn auch globale Variablen 😕



  • Techel, diese Andeutung nehme ich zur Kenntnis und zu Herzen, soweit ich es hinbekomme, werd ich mir keine Scope-Probleme o.ä. machen mit globalen Variablen. Und wenn ich das jetzt falsch auffasse, bitte mich aufklären, was ich genau nicht benutzen soll, oder welches Pattern stattdessen usw.

    In meinem Fall hätte ich einfach besser auf die Reihenfolge von Destruktor-Aufrufen achten müssen, ich war einfach mental ein bisschen in einer "speichersicheren" Scriptingumgebung (oder "Smartpointerumgebung") verfangen, wo man natürlich nicht wirklich auf Objekte mit "totem" Speicher stößt, sondern nur auf die restlichen Fehlertypen.

    Rust ist nicht die Lösung. Das war nur so dahingesagt. Ich muss einfach gründlicher sein.

    Ich will auch seit längerem mal wieder ein C++-Buch lesen, aber meine Angst ist, dass ich mit nutzlosen C++-Deklarationen konfrontiert werde. Ich hasse das Include-Guard-Verfahren wie die Pest und schreibe stattdessen Code, der mit lazycplusplus.com vergleichbar ist, weil ich es mir als einziger Projekt-Teilnehmer leisten kann, hier unkonventionell zu sein. Genau genommen sind alle Programmteile so geordnet, dass - von anderen Prioritäten abgesehen - die geringstmögliche Anzahl von Vorausdeklarationen entsteht, und natürlich gar keine unnötien Deklarationen.

    Ich google gerade, dass dieses Problem eigentlich eine ziemlich alte Kamelle ist. Aber ich weiss trotzdem nicht, wann ich diesen Punkt zum Thema DRY mal in einem C++-Buch gefunden hätte. Vielleicht begehe ich so den Fehler, viele Goodies aus Büchern zu verpassen, wenn ich dieses eine Goodie für so wichtig erachte und C++ eher als Relikt betrachte. Aber ich krieg eben bei überflüssigem Code die Krise.

    Bitte sag(t) mir ein modernes Buch zu C++, mit dessen Hilfe man keinen Boilerplate-Code schreibt, ich werde es umgehend versuchen zu lesen. Hauptsache: Mein Projekt wird gut und ich sterbe nicht dumm.

    Gleichermaßen ist mir übrigens die Visual C++ IDE einfach zu aufgebläht. Dass die jetzt Profilen kann, ist toll. Aber das Ding erschlägt mich.



  • VisualStudio sieht auf dem Blick verwirrend aus, hat dann aber doch seinen Nutzen 😉
    Globale Variablen sind stets, jedenfalls fast, zu vermeiden, besonders wenn der Spaß nicht trivial konstruiert und zerstört wird, ist Vorsicht geboten. Stattdessen eben die Objekte dann erstellen, wenn du sie brauchst.
    Ein Buch kann ich dir nicht empfehlen, weiß da keins, du kannst jedoch mal in der Bücherecke vorbeischauen.


Log in to reply