SOLVED: Brauche einen Rat beim Debuggen...



  • der Debug-Heap ist im Debug-Modus schon aktiv - man kann die Prüfungstiefe aber noch konfigurieren

    https://msdn.microsoft.com/de-de/library/974tc9t1.aspx



  • Und für die Ausgabe von Pointern gibt es bei printf %p
    Das passt dann auch zum Speichermodell.

    %i ist (bei Windows) für 32-Bit int (mit Vorzeichen) da. Für 64-Bit Pointer also völlig ungeeignet.



  • CJens schrieb:

    Also, weil hier andere User (nicht Du) gerne mal empfindlich reagieren: Mir ist klar, dass ich keinen Compilerfehler entdeckt habe.

    Also, nur am Rande... Compilerfehler sind natürlich auch nicht ausgeschlossen. Im SP2 hat Microsoft auch einige gefixt. Wir haben auch selber schon mindestens einen gefunden.



  • Fehler gefunden?



  • Was ist denn der erste Wert der sich ändert?
    M?
    M->pNode?
    Oder wirklich nur M->pNode[359].Gamma[3]?

    Ansonsten... wenn das reiner C Code ist in dem das Problem auftritt, dann nimm doch einfach den "nur native" Debugger statt des Mixed-Mode Debuggers. Sollte weniger Probleme machen.



  • hustbaer schrieb:

    Was ist denn der erste Wert der sich ändert?
    M?
    M->pNode?
    Oder wirklich nur M->pNode[359].Gamma[3]?

    Ansonsten... wenn das reiner C Code ist in dem das Problem auftritt, dann nimm doch einfach den "nur native" Debugger statt des Mixed-Mode Debuggers. Sollte weniger Probleme machen.

    Hallo.

    Es ändert sich nur M->pNode[359].Gamma[3] soweit ich das sehe. Das Problem ist ja, dass kein Fehler auftritt und diese Veränderung sich nur minimal auf meine nachfolgende Berechung auswirkt. Man muss also sehr genau hinsehen um den Fehler im Gesamtergebnis zu sehen. Andere Fehler konnte ich nicht ausmachen.

    Ich nutze jetzt den nativen Debugger. Also, die DLL habe ich jetzt als Executable rausgeschrieben.

    Ich habe jetzt die "Debugging Tools for Windows (x64)" installiert. Ich muss mich da aber erstmal etwas einlesen, denn ich verstehe das noch nicht ganz.

    ABER: Wenn ich das komplette Programm mit Visual Studio 2013 ausführe tritt zwar dieser Fehler nicht auf, aber das Programm friert dann recht schnell ein. Also... irgendwo ist das auf jeden Fall der Wurm drinnen, weshalb ich nur ungerne weiter arbeiten möchte, solange ich diesen Käfer nicht gefunden habe.



  • JUHUUUUUUU!!!!!

    Ich habe den Fehler gefunden. Er lag tatsächlich weit vorher. Diese "Debugging Tools for Windows (x64)" sind wirklich super. Ich hätte das sonst nie gefunden.

    Vielen Dank für alle Zuschriften. Jetzt weiß ich auch künftig, wie ich an so etwas rangehen muss.

    Danke danke danke!!!



  • kannst du den Code unter Linux kompilieren - oder bekommst du das hin, dann könntest du den gcc address-sanitizer verwenden (einfach live usb-image mit Ubuntu 16.04 starten - da ist der gcc 5.3 dabei)



  • Ich habe den Fehler gefunden. Er lag tatsächlich weit vorher. Diese "Debugging Tools for Windows (x64)" sind wirklich super. Ich hätte das sonst nie gefunden.

    was war es - und wie haben die Debugging Tools genau geholfen?



  • Wäre jetzt noch interessant welches Tool/welche Funktion bzw. Einstellung du verwendet hast um den Fehler zu finden. Und welcher Art der Fehler war.



  • Naja, das Debugging Tool hat geholfen indem es mir überhaupt mal gezeigt hat, wann ich im Heap über den Speicher hinaus geschrieben habe. Denn das, was Du da im Video gesehen hast läuft ja problemlos durch, wenn ich das Tool deaktiviere. Und die Heapcorruption wirkt sich dann erst später negativ aus.

    Der Fehler lag darin, dass ich bereits zu einem viel früheren Zeitpunkt Speicher für N->Gamma reserviert hatte. Das hat das Tool natürlich nicht aufgezeigt, aber darauf konnte ich dann relativ leicht kommen, nachdem das Tool die Stelle identifiziert hat.

    Überhaupt hilft mir das Tool, denn das Programm läuft seit einem halben Jahr und bringt den Fehler nur bei einer bestimmten Datei. Das heißt, seit einem halben Jahr arbeite ich relativ problemlos mit meinem Programm, das eigentlich fehlerhaft ist. Das Tool hat mir auch noch andere Stellen aufgezeigt, die buggy waren. 😮

    Ich habe das Gefühl, ich bin heute ein etwas besserer - oder ein etwas weniger schlechter - Programmierer geworden 🙂



  • hustbaer schrieb:

    Wäre jetzt noch interessant welches Tool/welche Funktion bzw. Einstellung du verwendet hast um den Fehler zu finden. Und welcher Art der Fehler war.

    Ich beschreibe es mal.

    Die Debugging Tools for Windows kann man hier downloaden:
    https://msdn.microsoft.com/en-us/windows/hardware/hh852365
    Runterscrollen und dann auf "Get Debugging Tools for Windows (WinDbg) (from the SDK)" klicken.

    Details zum Umgang findet man hier - daran hatte ich mich orientiert:
    https://support.microsoft.com/de-de/kb/286470

    Konkret: Nachdem ich die Tool installiert hatte habe ich die Eingabeaufforderung gestartet und folgendes eingegeben:
    *
    C:\Program Files\Debugging Tools for Windows (x64)\gflags.exe -r +hpa
    *

    Dann muss man den Computer neu starten. Das habe ich getan und Visual Studio gestartet. Ich habe das Programm ausgeführt und just hat der Debugger angeschlagen. Dann habe ich den Fehler korrigiert.

    Anschließend sollte man das Tool wieder deaktivieren. Das geht wie folgt:

    C:\Program Files\Debugging Tools for Windows (x64)\gflags.exe -r -hpa
    *

    Und den Rechner neu starten.



  • Cool, danke für die Antwort.

    D.h. du hast den Page-Heap aktiviert. Ja, der ist schon praktisch, der Page-Heap. Vorausgesetzt man hat genug Speicher dass das Programm damit überhaupt noch läuft 🙂

    Man muss aber überhaupt nicht rebooten, man kann mit gflags auch Einstellungen machen die nur für bestimmte EXEn greifen. Die greifen dann sofort (EXE neu starten muss man natürlich). Und vor allem kann man nur so den "full" Page-Heap verwenden.



  • hustbaer schrieb:

    Cool, danke für die Antwort.

    D.h. du hast den Page-Heap aktiviert. Ja, der ist schon praktisch, der Page-Heap. Vorausgesetzt man hat genug Speicher dass das Programm damit überhaupt noch läuft 🙂

    Man muss aber überhaupt nicht rebooten, man kann mit gflags auch Einstellungen machen die nur für bestimmte EXEn greifen. Die greifen dann sofort (EXE neu starten muss man natürlich). Und vor allem kann man nur so den "full" Page-Heap verwenden.

    Meinst Du mit:

    Gflags.exe –p /enable Application.exe /full
    *

    bzw.

    Gflags.exe –p /disable Application.exe /full
    *

    Ich hatte das versucht und es hatte (bei mir) nicht funktioniert.



  • Ich hab da immer irgend ein GUI Frontend dafür verwendet.
    Beim Pfad war irgendwas, da kann ich mich auch noch erinner. Kann sein dass man den absoluten Pfad angeben muss weil's sonst net funktioniert.



  • hustbaer schrieb:

    Ich hab da immer irgend ein GUI Frontend dafür verwendet.
    Beim Pfad war irgendwas, da kann ich mich auch noch erinner. Kann sein dass man den absoluten Pfad angeben muss weil's sonst net funktioniert.

    Werde es mal versuchen. Das kann natürlich sein. Ich kann auch mal versuchen, das in die Comments von Visual Studio einzutragen.

    Schade, dass solche Infos in normaler Literatur nicht zu finden sind. Sicher gibt es dazu Spezialliteratur... aber wenn ich sehe, wie lange ich manchmal nach Bugs gesucht habe und dann diese Möglichkeiten sehe.... wow.


Anmelden zum Antworten