Automatische Fehlersuche in Computerprogrammen

Transkript

1 Automatische Fehlersuche in Computerprogrammen Andreas Zeller Softwaretechnik Ein Programm tut nicht, was es soll. Was nun? Was den Anwender hilflos dastehen lässt, ist für den Programmierer der Beginn einer langen Detektivarbeit. Aus den Symptomen des Fehlers (etwa Diese Anwendung wird wegen eines ungültigen Vorgangs geschlossen") muss der Programmierer Das kennt fast jeder Computerbenutzer: Das Programm läuft nicht so, wie es soll. Was den einzelnen Zeit und Mühe kostet, summiert sich gesamtwirtschaftlich zu Schäden in Milliardenhöhe. Eine neue Generation von Werkzeugen schickt sich nun an, die Fehlersuche zu automatisieren: Seit Beginn des Jahres ist an der Universität des Saarlandes AskIgor in Betrieb der erste vollautomatische Dienst zur Fehlersuche in Computerprogrammen. zurückverfolgen, wie der Fehler auftreten konnte, die Ursache im Programmcode isolieren, das Programm so korrigieren, dass der Fehler nicht mehr auftritt, und dabei hoffentlich keine anderen Fehler einführen. Die Hauptarbeit bei der Fehlersuche ist, den Weg von der Ursache im Programmcode zum Auftreten des Fehlers zu rekonstruieren die sogenannte Ursache-Wirkungs-Kette. Abbildung 1 zeigt diesen Weg: Ein Programmlauf besteht aus einer Abfolge von Programmzuständen. Ein Programmzustand wiederum ist eine Menge von Variablen (Speicherzellen) und deren Werten (Inhalte). Wird nun ein Stück fehlerhafter Code ausgeführt, kann es zu einem ungültigen Zustand kommen der Zustand ist infiziert. Diese Infektion kann sich nun in der weiteren Berechnung weiter ausbreiten bis sie dem Benutzer als Symptom eines Fehlschlags offenbar wird. entsprechen oder ob sie bereits infiziert sind. Fehlersuche in der Praxis Was schematisch so einfach aussieht, ist in der Praxis ein Problem. Zunächst einmal sind die einzelnen Zustände recht gross Zustände, die zehntausend bis Millionen von Variablen umfassen, sind keine Seltenheit. Abbildung 2 zeigt einen infizierten Programmzustand des GNU-Compilers, eines Grundbausteins des Linux-Betriebssystems. Er besteht aus gut Variablen, die über Verweise miteinander verbunden sind. Die Infektion besteht darin, dass einer der Verweise falsch ist also die falschen Variablen miteinander verbindet. Selbst Experten brauchen einige Stunden, um diese Infektion einzugrenzen. Der Programmierer muss nun die Ursache-Wirkungs-Kette vom fehlerhaften Code bis zum Fehlschlag isolieren (hier rot dargestellt). Da der fehlerhafte Code noch nicht bekannt ist, beginnt der Programmierer beim Symptom (dem Endzustand) und arbeitet sich rückwärts bis zur Ursache vor. Dabei setzt er spezielle Werkzeuge ein, die es ihm erlauben, Programmzustände während des Ablaufs zu untersuchen, und sie zu prüfen, ob sie den Erwartungen Abb. 1: So schlägt ein Programm fehl. Beim Ausführen eines fehlerhaften Programmcodes wird der Programmzustand infiziert. Die Infektion breitet sich entlang einer Ursachen-Wirkungs-Kette aus, bis der Anwender sie als Fehlschlagen wahrnimmt. 18 Universität des Saarlandes

2 Zum zweiten ist ein Programmlauf recht lang; er kann ebenfalls Millionen bis Milliarden von Zuständen umfassen. Im obigen Beispiel muss der Programmierer also nachvollziehen, woher der falsche Verweis stammt. Im Prinzip kann in jedem Schritt jede der Variablen jede andere beeinflussen eine fast unlösbare Aufgabe. Und schließlich kann ein langer Inkubations"-Zeitraum zwischen Infektion und Auftreten des Fehlers liegen. All das sorgt dafür, dass manche Programmierer Nacht um Nacht mit Fehlersuche verbringen ohne jedoch alle Fehler beheben zu können. In der Vergangenheit hat sich die Forschung vornehmlich auf das Vermeiden von Fehlern konzentriert, entsprechend dem Motto Vorbeugen ist besser als Heilen. Zu den wichtigsten Ansätzen zählt die Modularisierung das Aufteilen eines Programms in Komponenten, die sich nur entlang weniger, wohldefinierter Wege beeinflussen können. Auf diese Weise kann die Verbreitung von Infektionen hilfreich eingegrenzt werden. Auch werden Programme zunehmend mit eingebauten Sicherheitsprüfungen ausgestattet, die Infektionen früh erkennen und Alarm auslösen. Und schließlich können eine Reihe von Programmierfehlern gleich im Ansatz vermieden werden durch systematisches Gegenlesen und frühes, sorgfältiges Testen und Analysieren. All diese Ansätze gehen jedoch davon aus, dass der Programmierer sein Programm bis ins Detail kennt. Viele der heutigen Systeme sind aber aus einer Vielzahl von Komponenten zusammengesetzt, von denen der Programmierer nur einen Bruchteil selbst entwickelt hat der Rest ist hinzugekauft. Tritt nun ein Fehler in einer solch zugekauften Komponente auf, ist der Programmierer so hilflos wie ein Anwender. Und selbst wenn die einzelnen Komponenten in sich stimmig sind, treten viele Fehler jedoch erst durch das Zusammenspiel der Komponenten auf jedes Zahnrad ist perfekt gefertigt, und doch greifen die Zähne nicht richtig ineinander. Kurz: Trotz aller Vorbeugung kann es weiterhin zu Fehlern kommen, und hier war der Programmierer bisher auf sich allein gestellt. Automatische Fehlersuche Grundsätzlich ist es leicht, ein konkretes Fehlschlagen zu verhindern: Der Programmierer muss nichts weiter tun, als das Symptom zu erkennen und abzuschalten. In der Fehlersuche ist solch ein Vorgehen aber verpönt, da jederzeit gleichartige Fehler wieder auftreten können. Also gilt es, das Übel bei der Wurzel zu packen die Ursache zu beseitigen. Was ist eine Ursache? Eine Ursache eines Ereignisses (der Wirkung") ist ein vorangegangenes Ereignis, ohne das die Wirkung nicht aufgetreten wäre. Somit können wir Ursachen in verschiedenen Teilen der Programmausführung definieren: Die Ursache in der Programmeingabe ist eine Eingabe, ohne die der Fehler nicht aufgetreten wäre. Die Ursache im Programmzustand ist eine Variable, ohne deren Wert der Fehler nicht aufgetreten wäre. Die Ursache im Programmcode ist eine Anweisung, ohne die der Fehler nicht aufgetreten wäre. Beim Finden der Ursache-Wirkungs- Kette gehen Programmierer in genau dieser Reihenfolge vor. Zunächst bestimmt der Programmierer, welche Teile der Eingabe für den Fehler relevant sind: Tritt der Fehler nur bei bestimmten Abb.2: Der Programmzustand des GNU-Compilers. Von gut Variablen und Referenzen ist eine falsch aber welche? magazin forschung 1/

3 Eingaben auf? Gibt es Aspekte der Eingabe, die keinen Einfluss auf den Fehler haben? Anschliessend wird der Programmzustand im Programmlauf untersucht. Als allerletzter Schritt, wenn das Entstehen des Fehlers vollständig verstanden ist, isoliert und behebt der Programmierer die Ursache im Programmcode selbst. Zum Verstehen der Fehlerursachen in Programmeingabe und Programmzustand gehen Programmierer im wesentlichen experimentell vor: Durch systematische Versuche grenzen sie die möglichen Ursachen ein nicht anders als in den experimentellen Naturwissenschaften. Und wie in den Naturwissenschaften werden solche Experimente in der Regel von Hand ausgeführt. Tatsächlich lässt sich aber das Experimentieren mit Programmen erheblich automatisieren schliesslich ist jeder Aspekt des Experiments im Rechner beobachtbar, und Experimente lassen sich jederzeit deterministisch wiederholen. Alles, was man hierfür benötigt, ist ein automatischer Test eine Funktion, die angibt, ob ein Programmlauf erfolgreich war oder fehlgeschlagen ist. Als Beispiel betrachten wir den Internet-Browser Mozilla, die verbreitetste Alternative zu Microsofts Internet Explorer. Mozilla ist frei verfügbar und auf die Rückmeldung seiner Anwender angewiesen. Im Jahr 1999 meldete ein Benutzer, dass Mozilla beim Ausdrucken der Seite bugzilla.mozilla.org" abstürzt: Ok the following operations cause mozilla to crash consistently on my machine -> Start mozilla -> Go to bugzilla.mozilla.org -> Select search for bug -> Print to file setting the bottom and right margins to.50 (I use the file /var/ tmp/netscape.ps) -> Once it's done printing do the exact same thing again on the same file (/var/tmp/netscape.ps) -> This causes the browser to crash with a segfault In diesem Fall ist die Fehlerursache der Inhalt der auszudruckenden WWW- Seite. Laden wir nämlich eine leere WWW-Seite in den Browser, so funktioniert das Ausdrucken tadellos. Anders ausgedrückt: Ursache für den Absturz ist der Inhalt von bugzilla. mozilla org". Dem Programmierer hilft dies jedoch nicht weiter: Er möchte wissen, welcher Teil des Inhalts für den Absturz verantwortlich ist. Um diese Ursache weiter zu präzisieren, bedienen wir uns eines Verfahrens, das speziell für das experimentelle Einengen von Fehlerursachen entwickelt wurde das Delta Debugging - Verfahren. Delta Debugging geht von zwei Programmläufen, einem funktionierenden und einem fehlerhaften Lauf aus. Zwischen den Eingaben dieser beiden Läufen muss es einige Unterschiede geben. (Wären beide Eingaben gleich, müssten die Läufe dasselbe Ergebnis zeigen.) Delta Debugging ist nun in der Lage, eine Untermenge der Unterschiede anzuwenden womit man einen Lauf erhält, der zwischen funktionierendem und fehlerhaften Lauf liegt. Dieser neue Lauf wird nun geprüft: Tritt der Fehler erneut auf, so wird nun der Unterschied zwischen funktionierendem und neuem Lauf eingeengt; Tritt der Fehler nicht auf, wird der Unterschied zwischen neuem Lauf und fehlerhaftem Lauf eingeengt. Dieser Vorgang ist in Abbildung 3 schematisch dargestellt. Angewandt auf Mozilla gilt es nun, den Unterschied zwischen leerer Seite (funktioniert) und bugzilla.mozilla. org" (schlägt fehl) einzuengen. Hierzu müssen wir den Unterschied in kleinere Teilezerlegen in unserem Fall etwa in die einzelnen Zeichen der WWW-Seite. Weiterhin müssen wir die so entstehenden Teile automatisch prüfen lassen etwa mit einem Hilfsprogramm, das automatisch die oben beschriebenen Anweisungen ausführt (Mozilla starten, Seite laden, Drucken) und prüft, ob Mozilla den beschriebenen Fehler aufweist. Abb. 3: Eingrenzen von Fehlerursachen. Durch Vergleichen zweier Läufe und Einengen der Unterschiede wird die Fehlerursache systematisch eingegrenzt. 20 Universität des Saarlandes

4 In unserem Mozilla-Beispiel bedeutet das Anwenden einer Untermenge die Konstruktion einer neuen WWW-Seite, die zwischen funktionierender und fehlerverursachenden Seite liegt. Dies geschieht so: Delta Debugging bestimmt alle Zeichen, die in der fehlerverursachenden Seite, nicht jedoch in der funktionierenden Seite vorkommen. Die neue WWW-Seite wird nun aus der funktionierenden Seite konstruiert, indem die Hälfte dieser zusätzlichen Zeichen übernommen wird. Diese Seite wird dann geprüft, wie oben beschrieben. Die einfachste Anwendung von Delta Debugging ist das Vereinfachen der fehlerverursachenden Eingabe. Ein solcher Ablauf ist in Abbildung 4 dargestellt. Nach 90 Tests hat Delta Debugging die WWW-Seite auf ein einzelnes Element herunterreduziert: ein einfaches SELECT-Element, das auf der WWW-Seite als Auswahlmenü erscheint. Der Fehler tritt also genau dann auf, wenn das vollständige SELECT-Element, ein Auswahlmenü also gedruckt werden soll. Für den fehlersuchenden Programmierer ist diese Aussage ein entscheidender Hinweis ähnlich wie Der Wagen springt genau dann nicht an, wenn die alte Zündkerze im Motor steckt" für den Kfz-Techniker oder Das Flugzeug stürzt genau dann ab, wenn es beim Start ein Metallstück aufwirbelt" für den Experten, der Luftfahrtunfälle untersucht. Delta Debugging isoliert diese Ursache automatisch, ganz ohne Wissen um den Bauplan des Programms Prof. Dr. Andreas ZELLER, geb in Hanau. Studium der Informatik in Darmstadt, Promotion 1997 in Braunschweig, seit 2001 Lehrstuhl für Softwaretechnik an der Universität des Saarlandes. Die vorgestellten Arbeiten über automatische Fehlersuche wurden mehrfach ausgezeichnet, u.a. mit dem Ernst-Denert-Preis für Software Engineering, mit dem Eclipse Award von IBM und dem Distinguished Paper Award der ACM SIGSOFT. und ganz ohne Beteiligung eines Programmierers. Auch eine vereinfachte Eingabe kann immer noch zu groß sein, um Hinweise auf den Fehler zu geben. Manche Fehler treten nur in einem bestimmten Kontext auf und beim Versuch, den grossen Kontext zu verkleinern, können zigtausende Testläufe ins Land gehen. Eine effizientere Alternative ist es daher, Delta Debugging fehlerverursachende Unterschiede in der Eingabe suchen zu lassen eine kleine Teilmenge der Eingabe, deren Vorhandensein den Fehler bewirkt. Ob die Ursache vorhanden ist oder nicht der Kontext bleibt in beiden Fällen unverändert. Ein solcher Ablauf ist in Abbildung 5 dargestellt. Hier benötigt Delta Debugging nur wenige Tests, um das Kleiner- Zeichen <" des SELECT-Elements herauszuisolieren; die restliche (HTML)- Eingabe bleibt unverändert. Abb.4: Vereinfachen einer fehlerverursachenden Eingabe. Die 896 Zeilen lange Webseite erzeugt einen Fehler im Mozilla-Browser. 8 Zeichen daraus genügen, um den Fehler zu bewirken. Abb.5: Finden eines fehlerverursachenden Unterschieds. Ob der Mozilla-Fehler auftritt oder nicht entscheidet das erste Zeichen der Eingabe. Ohne dieses Kleiner-Zeichen ist das SELECT-Element unvollständig; der Abschnitt wird als Text SELECT" verstanden. Wie bei der Vereinfachung der Eingabe wird der Programmierer direkt auf die Fehlerursache gestoßen. Das Verfahren wird nun mit Unterstützung von IBM zum Bestandteil der Eclipse- Programmierumgebung: Programmierer können auf Knopfdruck die Fehlerursache isolieren lassen. Wie pflanzen sich Fehler fort? Mit einer Fehlerursache in der Eingabe ist es jedoch noch nicht getan. Der Programmierer muss noch verstehen, wie der Unterschied in der Eingabe letztendlich einen Unterschied im Verhalten bewirkt kurz gesagt, muss er die Ursache-Wirkungs-Kette von der Eingabe bis zum Fehlschlag kennen. Wie aber kommt man zu einem solchen Ergebnis? Es stellt sich heraus, dass Delta Debugging nicht nur äußere Umstände isolieren kann, sondern auch innere Umstände des Programmlaufs, magazin forschung 1/

5 die bestimmen, ob und wann ein Fehler auftritt. Wie funktioniert dieses Verfahren? Die Idee ist, fehlerverursachende Unterschiede zwischen Programmzuständen zu isolieren genauso, wie wir zuvor fehlerverursachende Unterschiede zwischen Eingaben isoliert haben. Voraussetzung ist ein Zugang zum Programmzustand also die Möglichkeit, den Zustand in Form von Programmvariablen zu lesen und zu verändern. Ein solcher Zugang wird von nahezu allen Programmierumgebungen automatisierbar bereitgestellt. Das eigentliche Verfahren ist in Abbildung 6 schematisch dargestellt. Erneut betrachten wir zwei Programmläufe einen fehlschlagenden und einen funktionierenden. Nun wählen wir einen bestimmten Zeitpunkt im Programmablauf und vergleichen die beiden Programmzustände miteinander. Im Beispiel des GNU-Compilers etwa finden wir 897 Variablen, die in den beiden Läufen unterschiedliche Werte haben. Jeder dieser Unterschiede ist sowohl Wirkung des Unterschieds in der Eingabe als auch Ursache für das Fehlschlagen oder funktionieren. Jedoch ist nicht jeder der 897 Unterschiede relevant für das Fehlschlagen womöglich reicht ein viel kleinerer Unterschied aus, um den Fehler zu bewirken. Mit Delta Debugging können wir nun diesen ursprünglichen Unterschied einengen, genauso, wie wir es bei Mozilla getan haben. Dies bedeutet, dass wir künstliche Zwischenzustände erzeugen eine Mischung aus dem funktionierenden" Zustand und dem fehlschlagenden" Zustand und prüfen, wie sich das Programm unter diesen Zwischenzuständen verhält. Letzten Endes lässt sich so der ursprüngliche Unterschied auf nur wenige Variablen (meist eine) einengen womit bewiesen ist, dass genau diese Variable den Fehler verursacht. Auch wenn die Variable nicht zwingend infiziert ist, so trägt sie doch relevant zum Fehler bei ein wertvoller Hinweis für den Programmierer. Wird das Verfahren an mehreren Stellen im Programmlauf wiederholt, erhalten wir vollautomatisch die Ursache-Wirkungs-Kette des Fehlers: Erst hatte Variable X den Wert Y, dann wurde dieser Zeiger auf Z gesetzt... und so Abb.6: Eingrenzen von fehlerverursachenden Programmzuständen. Fehlerverursachende Unterschiede zwischen Programmzuständen lassen sich ähnlich eingrenzen wie fehlerverursachende Unterschiede zwischen Programm-Eingaben. So erfährt der Programmierer, welcher Teil des Programmzustands den Fehler verursacht. Abb. 7: AskIgor ein automatischer Dienst zur Fehlersuche. Über die Web- Seite können Programmierer ihre Programme einreichen; AskIgor erklärt, wie das Fehlschlagen zustande kam. stürzte das Programm ab". Diese diagnostische Leistung ist um so höher einzuschätzen, als dass es bislang keinerlei Möglichkeit gab, komplexe Programme wie den GNU-Compiler überhaupt sinnvoll zu analysieren. Anders ausgedrückt: Womöglich haben 22 Universität des Saarlandes

6 wir ein Verfahren, mit dem tatsächlich der Großteil der bisher händischen Fehlersuche in Programmen voll automatisiert werden kann. Ein Verfahren, mit dem die IT-Industrie zig-millionen einsparen könnte. Ein automatischer Dienst zur Fehlersuche Von ersten Experimenten bis zur großtechnischen Anwendung ist es noch ein weiter Schritt. Zunächst einmal möchten wir unsere Ergebnisse validieren und konsolidieren das heißt, wir möchten Delta Debugging auf eine Vielzahl echter Programme mit echten Fehlern anwenden und so die Grenzen und Möglichkeiten des Verfahrens ausloten. Hauptproblem dabei: Woher bekommen wir fehlerhafte Programme? Seit Ende 2002 betreiben wir einen experimentellen Web-Dienst namens AskIgor ("Frag Igor"), in dem Anwender unter ihre fehlerhaften Programme einreichen können (Abbildung 7). Nach dem Einreichen macht sich Igor auf, mit Delta Debugging die Ursache- Wirkungs-Kette zu isolieren, und nach einigen Minuten erhält der Programmierer die Diagnose per (Abbildung 8). Für einen fehlergeplagten Programmierer hat es natürlich etwas verlockendes, statt einer nächtelangen Sitzung vor dem Rechner einfach Igor zu fragen" und schlafen zu gehen. Am 10. März 2003 waren bereits 150 Programme eingereicht, von denen mehr als zwei Drittel erfolgreich von AskIgor bearbeitet werden konnten. Noch sind diese Daten vorläufig; erst wenn wir die 1000-Programme-Grenze überschritten haben, können wir den Nutzen von AskIgor tatsächlich abschätzen. Bis jetzt sieht es so aus, als seien wir auf dem richtigen Weg: Die Anwender bewerteten die Diagnosen zu drei Vierteln als hilfreich oder besser. Abb. 8: Die Diagnose von AskIgor. Aus Variablen hat AskIgor diejenigen eingegrenzt, die den Fehler verursacht haben. Gemäß der Rückmeldungen werden wir Igor kalibrieren und verbessern und schrittweise vom Prototypen zum regulären und zuverlässigen Dienst ausbauen. Die Datenbank mit echten, fehlerhaften Programmen ist eine Fundgrube für alle Arten von empirischen Studien über Programmfehler und ihre Behebung. Anders gesagt: Es wird viel, sehr viel zu tun geben. Für die Zukunft verheißen Dienste wie AskIgor viel Gutes: Für den Programmierer, der weniger Zeit für die Fehlersuche aufwenden muss bis hin zum Anwender, dessen Probleme schneller und effizienter repariert werden können womöglich sogar weitgehend automatisch. Auch in Zukunft werden uns Fehler in technischen Geräten begleiten, und wir werden weiter viel Anlass zum Fluchen haben. Aber wenn Fehler in Zukunft automatisch isoliert und schnell behoben werden können das hat als Glück im Unglück doch etwas Tröstliches. Literatur Den AskIgor Debugging Server finden Sie unter Die Arbeiten des Lehrstuhls über Delta Debugging finden Sie online unter Die Literaturangaben in den Arbeiten führen Sie weiter zu den einschlägigen Arbeiten. magazin forschung 1/