SOLVED: Brauche einen Rat beim Debuggen...
-
Gast3 schrieb:
noch ein Tip:
das Fehler-Szenario so schnell wie möglich reduzieren
-bleib in C/C++ mit deinen Tests - lass C# erstmal raus
-mind 2. Testszenarien hart im Code - ein funktionierendes 1 falsches
z.B. nur in der Dll eine Textdatei oder sonstige Datengrundlage laden und durchjagen - Fehler reproduzierenich würde mir z.B. einfach eine init oder sonstige Routine in der Dll suchen und dort hart eine test_fehler() routinen einbauen die mir die Daten laed und die SubdivideOneFBox aufruft, wenn der dort nicht auftritt liegt der Fehler einfach irgendwo anders
schnell und einfach
Also, ich werde das tun. Aber während die DLL arbeitet, ruht ja der Code in C#. Und in der DLL wird der korrekte Wert berechnet und später überschrieben. Das geschieht ja alles, während C# ruht. Aber ich werde das mal versuchen umzuschreiben - ist auch zum Teil schon im Code vorgesehen, einfach auch, dass ich es evtl. online stellen kann.
-
@Gast3: Ich habe die DLL jetzt als Executable kompiliert und lade die gleiche Datei ein. Der Fehler tritt aber unabhängig davon auf - wieder bei einem realloc-Befehl.
Was kann dazu führen, dass realloc diesen Speicher überschreibt?
Kann es helfen, wenn ich das komplette Projekt inkl. der Datei, die gelesen wir, mal online stelle?
-
CJens schrieb:
Was kann dazu führen, dass realloc diesen Speicher überschreibt?
Das
- der Speicher vorher nicht für dich reserviert war.
- dein Zeiger auf nicht mehr gültigen Speicher zeigt, weil du nicht alle Kopien des Zeigers (nach einem realloc) ersetzt hast.
-
DirkB schrieb:
CJens schrieb:
Was kann dazu führen, dass realloc diesen Speicher überschreibt?
Das
- der Speicher vorher nicht für dich reserviert war.
- dein Zeiger auf nicht mehr gültigen Speicher zeigt, weil du nicht alle Kopien des Zeigers (nach einem realloc) ersetzt hast.Das kann ich eigentlich ausschließen, da ich den Speicher erst wenige Zeilen vorher reserviere und überprüfe. Außerdem dürfte die Funktion dann nicht den korrekten Wert liefern. Kann es daran liegen, dass ich weit vorher irgendwo über einen Index hinaus gelaufen bin?
-
Also, jetzt wirds etwas ekelhaft, aber vielleicht hilft das. Ich habe ja den Code der DLL so abgeändert, dass ich ihn auch als Executable ausführen kann.
Wenn ich das Projekt in VS 2015 kompiliere, tritt der Fehler auf.
Kompiliere ich es in VS2013, tritt der Fehler NICHT auf.
-
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)
