Eine Einführung in die Programmiersprache C und ... - C /C++ Ecke

Eine Einführung in die Informatik und die Programmiersprache C
36 Anhang B, Debugging Tips und Tricks
Compilerwarnungen beachten.
Ein Modul sollte sich möglichst ohne Warnungen compilieren lassen, jede verbleibende Warnung überprüfen, nicht
einfach ignorieren. Bei den Compileroptionen möglichst alle Warnungen einschalten.
Auf nicht initialisierte Variablen achten.
Probleme mit Programmteilen, die einmal laufen und anschliessend nie mehr, oder einmalig unkorrekt und anschliessend
fehlerfrei laufen, lassen sich oft auf uninitialisierte Variablen (Insbesondere Pointer) zurückführen.
Auf Überschreiten von Arraygrenzen achten
In C kann problemlos über Arraygrenzen hinaus geschrieben werden (oben und unten), was oft zu Totalabstürzen,
manchmal aber nur zur Veränderung von benachbarten Variablen führt (Schwer lokalisierbarer Fehler !!!). Möglicherweise
in Debugversion vor jedem Arrayzugriff Index auf Bereich überprüfen (Achtung, ineffizienter Code!)
Selbstüberprüfenden Code schreiben.
Zu Beginn jeder Funktion die Argumente auf Plausibilität prüfen, insbesondere NULL-Pointer. Testfunktionen schreiben,
die Datenstrukturen (Listen, Bäume, ...) auf ihre Integrität hin untersuchen. Diese Testroutinen beim Debuggen an
strategisch wichtigen Punkten aufrufen.
Fehler eingrenzen.
Durch Ausgaben, Statusanzeigen oder grobschrittiges Debuggen Fehler eingrenzen, bis fehlererzeugende Funktion oder
Codezeile lokalisiert ist. Eventuell Hilfscode schreiben um Fehler weiter einzugrenzen.
Fehler isolieren.
Funktionen, die als Fehlerquelle in Frage kommen durch vereinfachte Versionen ersetzen und prüfen ob Fehler verschwindet,
so kann fehlerhafte Funktion gefunden werden.
Funktionen separat testen.
Verdächtige Funktionen aus der Applikation entfernen und in ein einfaches Testprogramm einbauen, das die Funktion
während längerer Zeit mit Testdaten oder Zufallsdaten aufruft und das Ergebnis jeweils überprüft, dieser Test kann mit
einer Integritätskontrolle kombiniert werden.
Statusinformationen ausgeben
Systemzustand ausgeben, ev. auf LED oder freie Portbits, wenn keine andere Ausgabemöglichkeit vorhanden ist. So
kann der Lauf des Programms verfolgt und unerwünschtes Verhalten erkannt werden. Auch Timingprobleme können so
analysiert werden; dies ist meist sogar die einfachste Möglichkeit, Timingprobleme zu erkennen.
Bei Sporadischen Fehlern
Ein Logfile oder einen Tracebuffer (Grosses Array mit ausreichend Platz für Einträge, als Ringbuffer aufgebaut der
immer die n letzten Ereignisse bereit hält) einfügen, worin ständig Systemzustände oder wichtige Ereignisse (Funktionsaufrufe,
Argumente, Interrupts, Benutzereingaben, Systemzeit in ms/us) abspeichert werden. Im Fehlerfall den Inhalt
von Logfile oder Tracebuffer sichern. Die Analyse dieser Daten kann helfen, den Fehler zu lokalisieren.
Fehler in Speicherverwaltung
Bei Verdacht auf Fehler in Speicherverwaltung, oder auch als Vorsichtsmassnahme kann eine eigene Speicherverwaltung
benutzt werden, die auf typische Fehler in der Speicherbenutzung achtet: Rückgabe nicht allozierten Speichers,
doppelte Rückgabe desselben Speicherblocks, Allozieren aber nie Freigeben eines Speicherblockes, beschränkt auch
das Überschreiten der Speicherblockgrenzen (Block am Anfang und am Ende grösser machen und diese Schutzbereiche
mit Testmuster füllen, bei Rückgabe prüfen ob diese Testmuster unversehrt sind).
Spezialcode für Fehlerfall schreiben
Extracode schreiben, der beim Erkennen eines Fehlers aufgerufen wird und möglichst viele Informationen des aktuellen
Systemzustandes ausgibt oder in ein File schreibt, oder einen Breakpoint auf diesen Extracode setzen, so dass im Fehlerfall
der Debugger zum Zuge kommt.
Bei HW-naher Programmierung auf volatile und Stacküberlauf achten
Variablen die von der HW oder Interrupts verändert werden, müssen als volatile deklariert werden. Lokale Variablen
von Funktionen werden auf dem Stack abgelegt, lokale Arrays können bei Mikrokontrollern schnell zu Stacküberlauf
führen. Unerklärliches Fehlverhalten oder Abstürze können auch auf einen Stacküberlauf zurückzuführen sein.
Gedruckt am 11.09.2008 13:04:00 Letzte Änderung am: 11. September 2008 Version 2.4, I. Oesch 145/147