qtforum.de

Syntaxfehler und anderweitige Programmierfehler fallen einem dadurch auf, dass das Programm garnicht erst kompiliert werden kann oder sich an verschiedenen Stellen im Programm eine Fehlfunktion zeigt.

Gibt es jedoch Speicherzugriffsfehler, ist man jedoch schnell sehr ratlos - insbesondere wenn es sich um Speicherzugriffsfehler handelt, die nur sporadisch und nicht sichtbar an einer bestimmten Ablaufstelle auftreten.

Aktuell habe ich ein Programm, dass man 2-3 mal starten muss, ohne sofort mit einem Speicherzugriffsfehler abzubrechen. Wenn es aber dann erst einmal gestartet ist, läuft es sehr stabil.

In einem anderen Programm gibt es kein Fehler im laufenden Betrieb, allerdings gibt es beim Beenden eine Schutzverletzung.

Kennt jemand ein paar gute Tipps, die einem dabei helfen, solche Instabilitäten zu beseitigen?

Fehler bei Start oder Ende, oder reproduzierbare Fehler kann man sehr gut mit dem Debugger lokalisieren...

Und wie sieht es mit (scheinbar) willkürlichen Fehlern aus?

Wenn ein Speicherzugriffsfehler immer an der gleichen Stelle auftritt, dann lasse ich an verschiedenen Stellen Debug-Meldungen ausgeben, um den Fehler weiter einzugrenzen und schreibe den betroffenen Code um.

Wenn allerdings das Problem auftritt, dass ein Programm zum Crash neigt, aber dieser niemals bei identischen Funktionsaufrufen auftritt (man kann das Programm etwa 1-2 Minuten verwenden, dann ist es spätestens vorbei), dann weiss ich nicht mehr weiter.

Im Grunde sollte man beim Entwickeln natürlich Strategien haben, um undefiniertes Verhalten zu vermeiden. Aber wenn der Fehler einmal da ist, helfen z.B. folgende Varianten:

- ein guter Memoryprofiler. Unter Linux z.B. 'valgrind', oder
- Reduktion des Sourcecodes, bis der Fehler nicht mehr auftritt (hilft nicht in allen Fällen...)

Beide Varianten können unter Umständen sehr zeitaufwendig sein und sollten erst zum Einsatz kommen, wenn alle anderen Wege (Warnlevel des Compiler erhöhen und "Warning-Free" arbeiten; Kontrolle wichtiger Schlüsselstellen im Code; Kontrolle ob die Binary nicht etwa korrupt ist ("make distclean && qmake && make")) ausgeschöpft sind.

hth!

valgrind kann ich da nur empfehlen. Es gibt da ein paar Optionen die man noch anschalten sollten. Aber das findet man ganz schnell herraus, wenn man nur liest was das Programm so sagt.
Und dann kommen große Augen wieviel Millionen Speicherlecks es gibt. Wenn die alle Weg sind stürzt es dann auch weniger ab.

solarix hat geschrieben: - ein guter Memoryprofiler. Unter Linux z.B. 'valgrind', oder

Was wäre da für Windows das Mittel der Wahl?


Für Delphi und Borland C++ Builder gibt es ne echt richtig tolle Sache:

http://madshi.net/madExceptDescription.htm

Kennt jemand sowas für MSVC bzw. MinGw?

Da gibts nichts freies.
Ne saubere Programmierung ist halt alles
Unit-Tests usw.

Im Grunde sollte man beim Entwickeln natürlich Strategien haben, um undefiniertes Verhalten zu vermeiden.

Das ist die einzige effektive Waffe die in dem Spiel hasst.

Wenn noch multithreading und paar sehr seltene Conditions (race conditions sind sowieso der Hass) zukommen, hasst mit Debuggen und Fehlertracking fast NULL chance.
Wenn sowas vorkommt, bist dann schon auf der Verliererseite.

Klar passieren solche Fehler ... aber man hat eher ne chance das Ding rauszubekommen wenn man seinen code genau und theorethisch analysiert, als versuchen jegliche bedingung nachstellen zu koennen, und dann genau an der stelle zu landen wo es passiert.

Also klarer strukturierter Code, wo als Programmierer genau weisst was passiert und was da vorkommen kann und was ned ... ist halt gold wert
Aber mit der Zeit kriegt man auch bisserl nen Gefuehl fuer so kritische stellen.

Ciao ...

gdb ist sehr gut um segfaults zu debuggen. Einfach gdb "binary" und dann run eintippen. Sollte dann ein seagfault kommen, wird das Programm angehalten und du kannst "backtrace" tippen. Er listet dann alles auf, was mit dem segfault zu tun hat.