Ohne Titel. Nirgends eingereicht, nirgends veröffentlicht.

Gestern kam ein Anruf aus der Zukunft. Mein Freund Max Heinz Hans Bopo rief aus dem Mittwoch in den Dienstag, oder aus Japan nach Österreich. Es klingelte und ich fummelte mit dem Headset herum. Man könnte die Buchsen ruhig mal gut beschriften, störte ich mich bis ich die Stecker in den richtigen Eingängen am Laptop hatte.
Bopo meldete sich mit einem vertrauten, aber unpassendem "Seeaas". Ich war gestresst, freute mich zwar über den Anruf, wollte aber noch nicht so schnell darauf eingehen. Was wollte er um diese Zeit? Ich blickte auf die Uhr, es war 11 Uhr abends. "Was gibts?" fragte ich etwas genervt, ohne dass ich es danach klingen lassen wollte, fühlte mich zu offensiv, erklärte kurz meine Situation und hatte schon mehr Zeit mit der Einleitung verbracht als nötig war.
Er war gerade aufgestanden und wollte wissen wie die Lage stand. Nachdem er einfach so abgerissen war, nach dem Streit, kamen ihm in der Ferne wieder die versöhnlichen Worte ins Gedächtnis. Meine anfängliche Ruppigkeit rieb ihm die gespielt gute Laune etwas auf. Bei ihm war es 6 Uhr in der Früh. Er wollte noch die Gelegenheit auf ein Gespräch nutzen, bevor er sich in den Tag warf, wie er es mit vorsichtiger Euphorie formulierte. Ich erzählte ihm, dass ich schon etwas müde war. Er schwärmte vom Frühstück. Mehr als ein paar Belanglosigkeiten konnten wir nicht mehr austauschen. Das Gespräch riss ab und wir verblieben, zum zweiten Mal, ohne Abschied. Wireless connection lost! Na super, seufzte ich und konzentrierte mich wieder auf den Programmcode, der einen winzigen aber kritischen Fehler hatte.
Debugging nennt man diesen Prozess des Fehler ausmerzens und es gibt viele Arten von "Bugs", wie die Fehler genannt wurden. Da sind einerseits die Übersetzungs-Bugs, sozusagen Rechtschreib- und Grammatikfehler, die beim Übersetzen des Programms automatisch erkannt werden und deren Auftreten meist auf eine Schlampigkeit des Programmierers hindeuteten. Viele zeigen sich stolz, wenn sie nach stundenlangem Programmieren, schließlich den Code in eine ausführbare Datei übersetzen und sich kein einziger solcher Bug darin befindet. Ich musste gestehen, das war bei mir eher die Ausnahme. Es war entweder eine Variable nicht deklariert, ein Rechtschreibfehler oder ich hatte die falschen Parameter übergeben. Die seltenen Fälle in denen es mir doch gelang den Code ohne diese Fehler beim ersten Mal zu übersetzen riefen keine Wohlgefühle hervor. Die Häufigkeit dieser Fälle bewies, dass es sich dabei um Glück gehandelt haben musste.
Viel schlimmer aber sind die Laufzeitfehler, denn wie der Name schon sagt, treten sie erst in Erscheinung wenn das Programm läuft. Es sind Fehler, die nicht automatisch erkannt werden. Die teil niemals automatisch erkannt werden können, wenn der Computer nicht den Sinn des Codes begreift. Ein solcher Fehler tritt auf, wenn man beispielsweise einer Variable als Anfangswert eine 1 zuweist, wenn der Rest des Codes darauf baut, dass die Variable anfänglich mit 0 belegt wurde. Das ist jedoch noch ein einfacher Fehler, denn die 1 wurde ja selbst vergeben. Wenn aber der Anfangswert abhängig von Prozessen war die außerhalb meines Einflußes lagen, weil der Wert beispielsweise aus der Funktion einer fremden Bibliothek stammte, konnte es erheblich länger dauern den Fehler zu finden. Dann gab es noch Memory-Bugs, verbunden mit dem gefürchteten "Segmentation fault", Hardware-Bugs und jede Menge von denen die im Zimmer herumschwirrten weil das Licht brannte und das Fenster offen stand. Verdammt!
Am allerschlimmsten waren jedoch generell die Fehler, die mal auftraten und mal nicht, mal ganz am Anfang, ein anderes Mal in der Mitte und dann wieder wenn das Programm kurz davor war zu terminieren. Oder solche, deren Abhängigkeiten über einige Ecken und damit schwer nachzuvollziehen waren.
Vor so einem Problem stand ich und es hatte mich schon einigen Aufwand gekostet, den Fehler, bzw. den Befehl der den Fehler produzierte, zu lokalisieren. Die Methode dazu war relativ einfach. Man besorgte sich entweder einen Debugger und arbeitete mit diesem den Code Schritt für Schritt ab, oder man fügte an manchen Stellen "Echo-Queries" ein, das heisst, ich ließ das Programm laut vorsagen, was es gerade tat und schränkte den Kreis beständig ein - Debugging für Arme oder für jene die mit parallelen Prozessen zu tun hatten und sich mit Paralleldebuggern noch nicht auseinandergesetzt hatten.
Auf den ersten Blick sah alles korrekt aus, auf den zweiten Blick sah ich noch immer keinen von den typischen Fehlermustern, also musste ich das ganze pragmatisch angehen und alle Möglichkeiten in Betracht ziehen. Ich blickte wieder auf die Uhr. Es war schon halb eins und ich gähnte. Der Fehler lag im Bauch einer If-Condition. Also ließ ich mir alle Variablenbelegungen anzeigen, die für den Fehler von Bedeutung war und startete das Programm. Jede Menge Zahlen und Wörter flogen daraufhin über den Bildschirm. Ich schaute ihnen zu, verfolgte sie und konnte mir eine Ähnlichkeit mit "The Matrix" nicht leugnen. "Du siehst dir die Matrix unverschlüsselt an?" fragte ich mich selbst. "Aber klar!" stieß ich dann auch gleich hervor. "Weil das möglich wäre für das menschliche Gehirn. So ein Blödsinn" ereiferte ich mich darüber wie unrealistisch diese Fiktion war.
Die Zahlen wurden schließlich unsanft durch einen Segmentation fault unterbrochen. Es war offensichtlich, dass hier ein Wert nicht zugewiesen wurde, die Variable undefiniert blieb und die Ausnahme und in mir einen Wutanfall auslöste. Ich war müde, gähnte nochmals, prägte mir die Werte ein und ließ das Programm nochmals laufen. Ich hoffte auf andere Daten oder ein Muster. Die Matrix arbeitete von neuem, aber ich widmete mich derweil dem Code um die ersten Erkenntnisse vielleicht schon fruchtbringend umzusetzen.
Der Wert der Variable wurde nicht zugewiesen, das bedeutete, dass ich den Code überprüfen musste, der den Wert eigentlich zuweisen sollte. Das Mausrad antreibend steuerte ich durch den Quelltext, doch an besagtem Code war nicht auszusetzen, zumindest nicht direkt. Er musste also in Fällen ausgeführt werden, für die ich eine Ausführung nicht vorhersah, etwas an der If-Condition konnte nicht stimmen. Ich überlegte und wechselte zu meinem Program, das wieder mit einem Signal 11 Segmentation fault den Dienst quittierte. Aus den letzten Daten die ich ausgeben ließ konnte ich auch nicht mehr erkennen als beim ersten Mal. Gottseidank hatte ich schon eine Fährte, wechselte wieder zum Programmcode und nahm die If-Abfrage genauer unter die Lupe. "if (outcount > 0)" laß ich da. Das war zweifelsfrei richtig, denn wenn der outcount unter 0 lag, konnte kaum mit einem Output zu rechnen sein. Ich startete abermals das Programm um auch sicherzustellen, dass der Fehler zumindest immer an der selben Stelle auftrat. Ich sah also nach wo die Variable outcount gesetzt wurde und musste feststellen, dass es sich dabei um eine Funktion einer fremden Bibliothek handelte. Mit dieser Gewißheit überprüfte ich die Beschreibung der Funktion in den Manpages. Nach einigem Blättern stellte sich tatsächlich heraus, dass outcount für spezielle Eingaben einen speziellen Wert annehmen konnte und dieser lag ebenfalls über 0 (sehr schlau). Ich musste also diesen Fall abfragen und gesondert behandeln. Siegessicher begann ich daran den Code zu adaptieren und zwar möglichst geringfügig um nicht noch weitere Fehler einzubauen. Ich speicherte, übersetzte und startete das Programm neu. Die Matrix begann wieder zu rieseln. Das Programm lief munter fort, ich wartete, aber der Segmentation fault blieb aus, schließlich terminierte es fehlerfrei. Ich atmete auf, es war 2 Uhr früh und ich freute mich weniger über die Behebung des Bugs als vielmehr auf das Bett, das mich gleich erwarten würde. Die "Echo-Queries" musste ich noch entfernen, sicherheitshalber kommentierte ich sie erstmal aus. Löschen konnte ich sie später immer noch. Ich übersetzte das Programm nochmals. Ließ es noch ein paar Mal laufen, aber es endete immer korrekt. Ich konnte aufatmen, versetzte die Maschine in den Ruhezustand und kroch ins Bett.