tips zur fehlersuche
-
Aber es läuft doch. Keine Ahnung wie ich den Fehler provozieren kann.
-
Teste weiter. Gib es dein Programm mal noch anderen Leuten zum testen. Ansonsten Schwamm drüber.. (mach irgendwo einen Vermerk und warte ab..)
-
Oh mann, wie konnte ich bis jetzt nur OHNE Debugger arbeiten.
Obwohl es nicht zum Absturz kam ermittelte ich ein Segmentation Fault daß durch eine nicht zurückgesetzte Variable ausgelöst wurde. Dadurch daß Init automatisch ausgeführt wird, ich dann Init 3x neu startete und mit 4 der Max-wert erreicht war kam es zum Überlauf.
Ich verstehe nur nicht, daß das Programm trotzdem eigentlich fehlerfrei lief?
Eine Frage noch: Die Informationen des Segmentation Fault verwiesen auf verschiedene andere Header. Behoben habe ich es aber in einer ganz anderen Funktion, die nicht aufgelistet war. Ist das normal? Zum. ist der Fault jetzt weg.
-
Segmentation fault tritt ja auf, wenn du auf Speicher zugreifst, welcher dir eigentlich nicht oder nicht mehr gehört. Kommt durch Nullzeiger oder wildezeiger und ähnliches. Das Verhalten des Programmes ist da undefiniert, dass macht diesen Fehler so gefährlich. Undefiniert heisst genau das, was es heisst. Grundsätzlich könnte die Hölle gefrieren, das wäre auch korrektes Verhalten. Das Programm könnte aber auch ohne Probleme weiterlaufen, ist auch erlaubt ... usw. usf.
Deshalb sollte man wenn möglich immer entsprechende Bereichsüberprüfungen einbauen, ausser man ist sich GANZ SICHER, dass kein Überlauf oder ähnliches stattfinden wird.Und ja, solche Fehler behebt man manchmal Meilenweit entfernt vom eigentlichen Fehler, das ist durchaus üblich.
Ganz mühsam wird es, wenn der Fehler Speicher eines völlig anderen Objektes verändert und der veränderte Speicher dann an einer anderen Stelle zum Absturz führt. Es gibt in der Programmlogik dann überhaupt gar keine Verbindung zwischen den zwei Bereichen, ausser das halt zufällig der eine Zeiger genau an die falsche Stelle gezeigt hat
Grüssli
-
(s)printf. ist erstens C und prüft zweitens nicht ob der Speicher auf den es zugreift überhaupt dir gehört. Ein wunderbarer Kandidat für Speicherzugriffsfehler, überschriebene Rücksprungadressen (mein Favorit) und mehr schwer zu findende Späße.
Mein Tip: (s)printf ist zwar Bestandteil von C++. Aber seit 1998 gibts den C++ Standard, seit 1993 das ARM. und C++ Strings und Streams gabs schon davor. Nutz die Mittel des Standards, die dir Sicherheit vor Speicherzugriffsfehlern geben.
-
Nicht nur
printf(), sondern sehr viele Teile von C (gerade Zeichenkettenverwaltung) sind sehr anfällig auf Speicherzugriffsfehler, Memory Leaks und andere Unschönheiten. Wenn du C++ programmierst, solltest du auch dessen Vorteile nutzen.pumuckl schrieb:
überschrieben Rücksprungadressen (mein Favorit)
Ist dir das echt schon passiert? Wie verhielt sich das Programm dann?
-
Gar nicht erst Fehler machen, dann sparst du dir auch die nervige Suche
-
T0bi schrieb:
Gar nicht erst Fehler machen, dann sparst du dir auch die nervige Suche
Ich bin ja mal gespannt, wie du das mit deiner Signatur in Einklang bringen willst...
Real programmers code binary!
I never comment my sourcecode. What's HARD to write must be HARD to read!
-
Nexus schrieb:
Ist dir das echt schon passiert? Wie verhielt sich das Programm dann?
Ist einfach kommentarlos ausgestiegen. Der Clou an der Sache: das trat nur im Releasemodus auf. Im Debugmodus lief alles einwandfrei. Wir haben zu zweit einen kompletten Arbeitstag gebraucht um mit cout-Statements rauszufinden, dass zwar das Ende einer bestimmten Funktion erreicht wurde, aber das cout direkt nach dem Rücksprung nicht mehr ausgeführt wurde. Der Kollege hat dann mit irgendeinem Stack-monitor wohl gesehn dass es tatsächlich die Rücksprungadresse war, derweil durfte ich in der 3000-Zeilen Funktion suchen, welches von den 200 printf's auf ca. 30 char-buffern denn schuld war. Außer der Dateiendung und dem Compiler war da nicht viel C++ bei
-
Finde ich recht interessant...
Das sind halt die Momente, wo ich wieder froh bin, C++ programmieren zu dürfen.
(Wobei einem auch hier sehr mühsame Fehler unterlaufen können. ;))
