SOLVED: Brauche einen Rat beim Debuggen...
-
Wenn ich das Projekt in VS 2015 kompiliere, tritt der Fehler auf.
Kompiliere ich es in VS2013, tritt der Fehler NICHT auf.ich denke nicht das du einen Fehler in VStudio entdeckt hast sondern eher irgendein undefined-behavior oder sonstiges anstoesst - sowas merkt man oft bei Kompilerwechsel
Kann es helfen, wenn ich das komplette Projekt inkl. der Datei, die gelesen wir, mal online stelle?
wenn du es kannst/darfst - hilft es bestimmt mehr als es nicht zu tun
-
Gast3 schrieb:
Wenn ich das Projekt in VS 2015 kompiliere, tritt der Fehler auf.
Kompiliere ich es in VS2013, tritt der Fehler NICHT auf.ich denke nicht das du einen Fehler in VStudio entdeckt hast sondern eher irgendein undefined-behavior oder sonstiges anstoesst - sowas merkt man oft bei Kompilerwechsel
Kann es helfen, wenn ich das komplette Projekt inkl. der Datei, die gelesen wir, mal online stelle?
wenn du es kannst/darfst - hilft es bestimmt mehr als es nicht zu tun
Also, weil hier andere User (nicht Du) gerne mal empfindlich reagieren: Mir ist klar, dass ich keinen Compilerfehler entdeckt habe. VS2013 wird genau so korrekt arbeiten wie VS2015 - aber ich muss das ja hier posten, wenn ich es entdecke. Kann es an Einstellungen liegen? Kann ich den Compiler vielleicht noch etwas kleinlicher einstellen, dass er bei geringeren Fehler schon anspricht oder so? Optimierung ist in beiden Fällen deaktiviert - aber das wird ja glaube ich im Projekt gespeichert.
Ich habe hier nur sehr langsames Handy Internet, aber ich werde in etwa einer Stunde mal das Projekt hochladen UND ein Video auf Youtube stellen, welches den Fehler zeigt.
realloc überschreibt übrigens keinen verwendeten Speicher. N[359].Gamma[3] ist im aktuellen Fall in Adresse 3 987 192 gespeichert.
Der Speicher, welcher reserviert wird (bei npFace = 1) ist 3 987 248 - ist nur ein Feld, variiert natürlich bei jedem Ausführen.
-
Gibt es Fehlermeldungen beim Kompilieren?
Könnten (fehlerhafte) Fließkommaberechnungen den Fehler mitverursachen?
Gibt es schon eine Fehlertheorie(n) (verfehltes Speichermanagement, verdächtige Zeiger o.ä) ?
Wie sieht das Testszenario aus?
Was sagt die Fehlerdatenbank?
Breakpoints kann man zur Not auch von Hand setzen. Besser sind aber Fehlersuchtools für bestimmte Aufgaben.
Wie zeigt sich der Bug, bzw. wie hast du den Fehler überhaupt selbst entdeckt?
Eventuell gibt es keinen Fehler, alles nur ein Irrtum?Gibt es irgendwo (verdächtige) Zeitverzögerungen (Profiler o.ä.) ?
Eine stärkere Modulstruktur ist generell debuggingfreundlicher.
Guidelines kennen hilft ebenfalls z.B.:
http://www.informit.com/articles/article.aspx?p=1823696&seqNum=2
http://stackoverflow.com/questions/21006707/proper-usage-of-realloc
Außerdem lassen sich solche Guidelines/Guides gut automatisieren bzw. automatisiert testen.
-
nachtfeuer schrieb:
Gibt es Fehlermeldungen beim Kompilieren?
Nein, gibt keine.
nachtfeuer schrieb:
Könnten (fehlerhafte) Fließkommaberechnungen den Fehler mitverursachen?
Das glaube ich nicht. Ich lese mehrere tausend Zahlen ein - und ich gebe mir das Ergebnis anschließend aus. Die Koordinaten sind alle korrekt, sonst würde die 3D Darstellung des Gitters das zeigen.
nachtfeuer schrieb:
Gibt es schon eine Fehlertheorie(n) (verfehltes Speichermanagement, verdächtige Zeiger o.ä) ?
Ich denke, dass ich irgendwann beim Einlesen mit einem Zeigerindex über ein Feld hinaus fahre und dabei irgend etwas überschreibe, was mir später diesen Fehler verursacht. Ich habe eben mal alle Koordinaten die gelesen werden in MS Excel geladen, das Zahlenformat auf acht Nachkommastellen gesetzt, die Daten in der Datei ersetzt, dann trat exakt der gleiche Fehler etwas später in genau der gleichen Routine auf.
nachtfeuer schrieb:
Wie sieht das Testszenario aus?
Ich kann die Funktion, welche N[359].Gamma[3] erneut berechnet nach dem Einlesen nochmals manuell ausführen, dann Berechnungen starten. Ich kann die Poissongleichung auf dem Rechengitter lösen, das heißt, dass alles funktionieren muss. Es darf kein Wert falsch sein, sonst würde das Gleichungssystem nicht lösbar sein. Aber der Code stürzt manchmal unvorhergesehen ab.
Ich arbeite seit acht Monaten täglich an dem Code - ich fühle mich einfach nicht wohl, wenn ich weiß, dass das auftritt. Bei anderen Gitterdateien tritt das scheinbar nicht auf.nachtfeuer schrieb:
Breakpoints kann man zur Not auch von Hand setzen. Besser sind aber Fehlersuchtools für bestimmte Aufgaben.
Jetzt wo ich die DLL als Executabel ausführe, kann ich auch Breakpoints setzen und tue das auch. Aber die zeigen mir nichts anderes. Vor dem Realloc ist der Wert korrekt, danach nicht mehr.
nachtfeuer schrieb:
Wie zeigt sich der Bug, bzw. wie hast du den Fehler überhaupt selbst entdeckt?
Eventuell gibt es keinen Fehler, alles nur ein Irrtum?Ich habe den Fehler entdeckt, weil die Berechnungsergebnisse um diesen Punkt nicht korrekt dargestellt wurden.
Gibt es irgendwo (verdächtige) Zeitverzögerungen (Profiler o.ä.) ?
Eine stärkere Modulstruktur ist generell debuggingfreundlicher.
Aber es ist wirklich auffällig, dass das gleiche Projekt mit VS2013 den Fehler nicht zeigt.
-
CJens schrieb:
realloc überschreibt übrigens keinen verwendeten Speicher. N[359].Gamma[3] ist im aktuellen Fall in Adresse 3 987 192 gespeichert.
Der Speicher, welcher reserviert wird (bei npFace = 1) ist 3 987 248 - ist nur ein Feld, variiert natürlich bei jedem Ausführen.Wie kommst du an die Adressen?
Hast du schon den Debugheap von VS benutzt?
-
Ich habe noch etwas heraus gefunden. Wenn ich die Andwendung in VS2013 kompiliere und ausführe, arbeitet sie korrekt. Wenn ich dann in VS2013 die DLL erstelle und diese dann über meine GUI aufrufe, arbeitet sie wieder nicht korrekt. Hat das mti der Runtime zutun?
Wenn ich die C# GUI in VS 2013 starte, arbeitet auch alles korrekt.
-
DirkB schrieb:
CJens schrieb:
realloc überschreibt übrigens keinen verwendeten Speicher. N[359].Gamma[3] ist im aktuellen Fall in Adresse 3 987 192 gespeichert.
Der Speicher, welcher reserviert wird (bei npFace = 1) ist 3 987 248 - ist nur ein Feld, variiert natürlich bei jedem Ausführen.Wie kommst du an die Adressen?
Hast du schon den Debugheap von VS benutzt?
Die Adresse habe ich, indem ich diese über %i ausgebe.
Nein, ich kenne keinen Debugheap. Werde das mal googeln.
Gibt es da nativ was von Visual Studio oder muss man das in jedem Fall installieren?
-
der Debug-Heap ist im Debug-Modus schon aktiv - man kann die Prüfungstiefe aber noch konfigurieren
-
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/286470Konkret: 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.
