Programme debuggen

Programmieren ist eine komplexe Angelegenheit. Nur die wenigsten schaffen es mehr als 10 Zeilen fehlerfrei zu schreiben. Erst recht nicht als Anfänger. Häufig meiste Zeit bei Programmentwicklung für Fehlersuche (=debuggen) und Korrektur.

Hilfreich Fehler zu klassifizieren:

Syntax–Fehler: Der Python Interpreter kann ein Programm nur übersetzen wenn die Syntax des Programms korrekt ist, d.h. den Python Regeln entspricht. Beispielsweise nicht kompatible Datentypen in Operationen, falsche key-words, fehlende Klammern, unbekannte Funktionen oder Klasse, und vieles andere. Besonders für Anfänger häufigste Fehlerquelle und ziemlich lästig wegen kryptischer Fehlermeldungen des Interpreters, dennoch einfachste Art von Fehler.
Laufzeit–Fehler treten beim Ausführen des Programms auf (= run-time errors) und führen i.d.R. zum Abbruch des Programms, z.B. Division durch Null, File existiert nicht, Speicherüberlauf, Zugriff auf nicht-existierende Array Elemente, etc. Manchmal offensichtlich, oft aber auch schwer und mühsam zu finden. Python ziemlich sicher und gutmütig im Vergleich mit C, C++, FORTRAN, ... In Python integriertes System zum exception–handling (weiteres später).
Semantik–Fehler Programm kompiliert und läuft, tut aber nicht das was es soll. Mal einfach, kann aber auch Menschenleben oder Milliarden kosten (Ariane-5 Absturz, Patriot-Crash, ..., siehe Collection of Software Bugs).

The First "Computer Bug"

Moth found trapped between points at Relay # 70, Panel F, of the Mark II Aiken Relay Calculator while it was being tested at Harvard University, 9 September 1945. The operators affixed the moth to the computer log, with the entry: "First actual case of bug being found". They put out the word that they had "debugged" the machine, thus introducing the term "debugging a computer program". In 1988, the log, with the moth still taped by the entry, was in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia.

Apple goto-fail bug

Aktuelles (2014) Beispiel für sicherheitsrelevanten Bug in Apple IOS 7 (C-Programmcode).

// ...
hashOut.data = hashes + SSL_MD5_DIGEST_LEN;
hashOut.length = SSL_SHA1_DIGEST_LEN;
if ((err = SSLFreeBuffer(&hashCtx)) != 0)
    goto fail;
if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0)
    goto fail;
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail; 
if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0)
    goto fail;

err = sslRawVerify(...);
//...

Entscheidender Check ( sslRawVerify()) wird u.U. nicht ausgeführt, ermöglicht Angriffe auf verschlüsselte (TLS/SSL) Verbindungen.

Debugger

Meiste Zeit bei Programmentwicklung i.d.R. für (Laufzeit-/Semantik-) Fehlersuche.
In Python oft interaktives Ausprobieren möglich zur schnellen Fehlersuche, ansonsten ist Standardverfahren print statements an den kritischen Stellen.
$\bgroup\color{dgreen}$\Rightarrow$\egroup$ umständlich, zeitraubend

Wesentlich eleganter mit richtigem debugger

Programm läuft unter Kontrolle des Debuggers
Zeile für Zeile dem Source-code nach
oder breakpoints an den kritischen Stellen setzen und direkt dahin laufen.
Inhalt von Variablen kann angezeigt werden. Bewirkt dass zusätzliche Info in den kompilierten code geschrieben wird.
Klassischer Kommandozeilen-Debugger:
Starten mit Module pdb: python3 -m pdb tprime.py
Oder Integrierter Debugger mit GUI, z.B. in Python Entwicklungsumgebung idle : idle-python3.6 tprime.py (oder auch spyder)
Neue Version des JupyterHUB erlaubt auch Ausführen von Code-cells in vollem GUI Debug Mode