Die Fehlersuche in großen Serverapplikationen ist eine schwierige Aufgabe, da diese Applikationen meist nebenläufig ausgeführt werden und zeitkritisch sind. Statische Codeanalyse ist oft nicht ausreichend und schrittweises Debugging ist nicht durchführbar. Die Fehlersuche wird zusätzlich erschwert, wenn die Serverprogramme in objekt-orientierten Programmiersprachen verfasst sind, da viele etablierte Techniken, wie zum Beispiel die klassische Kontrollflussanalyse, wegen der Klassenableitungen, Methodenüberschreibungen und dynamischen Bindung von Code nicht mehr direkt angewandt werden können. In diesem Buch werden die Grundlagen für dieÜberwachung von laufenden, in objektorientierten Sprachen verfassten Serverapplikationen präsentiert.

Das Konzept der hier vorgestellten Lösung beruht auf derÜberwachung des Programmcodes an bestimmten Stellen. Bei fehlerhaftem Verhalten kann aus den protokollierten Ereignissen der Ablauf bis zur fehlerhaften Stelle in dem Programm rekonstruiert werden. Die Auswahl der Positionen für die Ereignisfunktionen basiert auf graphentheoretischen Algorithmen, die die Menge der Positionen für dieÜberwachung signifikant reduzieren. Dieses Buch richtet sich an alle Informatiker, an Studenten des Faches sowie den interessierten Leser.

Der Autor

Sergej Alekseev, Dr. rer.nat. hat 2006 seine Promotion an der Universität Oldenburg abgeschlossen. Er arbeitete von 1999 bis 2003 als Software-Entwickler in der Abteilung„Intelligente Netze" bei Siemens AG. Nach der Promotion ging er zurück zu Siemens AG, wo er die Forschungsgruppe„Testme hoden" bei Communication Mobile Networks in Berlin leitet.

Kapitel 2 Aktueller Stand der Software-Fehleranalyse (S. 5-6)

Dieses Kapitel soll einen Einstieg in die Thematik dieser Arbeit ermöglichen. Zuerst wird der Begriff„Fehler" erläutert und eine De.nition des Fehlers eingeführt. Danach wird auf die existierenden Techniken für die Fehlerlokalisierung eingegangen und ein Beispiel der Fehlersuche vorgestellt, um die Bedeutung der Ablaufanalyse zu veranschaulichen. Im weiteren wird die Problemstellung festgelegt und die verwandten Arbeiten untersucht, die sich mit dieser Thematik befassen.

2.1 Fehler

Spricht manüber Fehler in der Ausführung eines Programms, so .nden Begriffe wie error, failure, fault und bug ihre Verwendung. Hierzu existiert in der Literatur eine Reihe oft unterschiedlicher De.nitionen. Eine gebräuchliche, wenn auch informale Definition für den Begriff Fehler (hier error gemeint), liefert [Cla03]. Demnach ist ein Fehler die Ermittlung oder Ausgabe eines falschen Ergebnisses durch eine Rechenanlage. Man unterscheidet des Weiteren Hardwareund Softwarefehler. Diese Arbeit konzentriert sich auf Softwarefehler, welche aus der falschen Anweisungsfolge innerhalb eines Programms resultieren. Dies kann zum Beispiel durch eine fehlerhafte Implementierung oder durch falsche Algorithmen entstehen.

Erschwert wird die Begriffswahl auch dadurch, dass eine Unterscheidung zwischen dem beobachteten Fehler (Folgefehler) und dem eigentlichen Fehler erfolgen muss. Beim eigentlichen Fehler ist der Programmzustand, in welchem er initial auftritt, von Bedeutung. Bei den meisten beobachteten Fehlern handelt es sich hingegen um Folgefehler. Solch ein Folgefehler existiert immer nur als Konsequenz und erschwert dabei die Suche nach dem eigentlichen Fehler. Aus diesenÜberlegungen lässt sich folgende De.nition eines Fehlers formulieren:

Definition 2.1 Ein Fehler (error) in einem Programm wird durch einen inkorrekten Programmzustand st ersichtlich. Dieser ist dann dadurch gekennzeichnet, dass eine oder mehrere Variablen einen inkorrekten Wert zum Zeitpunktt besitzen.

Hierzu wird in der Literatur auch der Begriff des dynamischen bzw. Laufzeitfehlers verwendet. Diesem stehen Fehler gegenüber, welche zur Zeit derÜbersetzung (Kompilierung) eines Programms auftreten. Letztere resultieren zum Beispiel aus Fehlern in der Programmsyntax (statische Fehler). Die Laufzeitfehler bilden die logischen Fehler, die durch eine falsche Anordnung von ansonsten syntaktisch korrekten Programmanweisungen entstehen. Deren Auf.nden ist mit hohem Aufwand verbunden, da sie in der Regel nicht vom Programm erkannt werden.

Stattdessen liefert das Programm lediglich ein falsches Ergebnis. Der Nutzer muss daher den Programmablauf analysieren, um den eigentlichen Fehler (die Ursache für Folgefehler) zu finden. Der Laufzeitfehler und der Fehler (De.nition 2.1) haben in dieser Arbeit die gleiche Bedeutung.

2.2 Existierende Techniken

Es gibt mehrere Strategien, um Fehler zu lokalisieren und deren Ursachen zu finden:

• Schritt für Schritt Debugging von Programmen
• und Logging während der Ausführung des Programms
• Post-Mortem Analyse nach dem Absturz eines Programms (core-dump)

Debugging

Debugger ermöglichen, ein Programm Schritt für Schritt auszuführen und bei jedem Schritt den Zustand des Programms zu kontrollieren [Ric04]. Um die Fehlersuche zu erleichtern, können Visualisierungswerkzeuge eingesetzt werden wie zum Beispiel der Data Display Debugger (DDD) [Nor03].

Tracing

Um sich einenÜberblicküber ein Programm während der Ausführung zu verschaffen, kann das Programm mit Ausgabefunktionen instrumentiert werden. Zum Beispiel können in C/C++ die printf-Anweisung und in java die System.out.print-Anweisung dafür benutzt werden. Diese Anweisungen können jedoch nicht immer alle Kontrollpfade abdecken und sie können sogar manchmal selbst Fehler verursachen. Das nächste Problem ist, dass die permanent laufenden Server-Applikationen in kurzer Zeit eine große Menge von Daten generieren können, was das Leistungsverhalten des Gesamtsystem negativ beein.ussen kann.

core-Dumps

Die modernen Betriebssysteme haben die Möglichkeit den Zustand eines Prozesses im Fehlerfall in einer Datei (core-dump) abzuspeichern. Diese Datei enthält folgende Informationenüber den Prozess zum Zeitpunukt des Auftretens des Fehlers:

• Registerinhalt
• Adressen der zuletzt ausgeführten Instruktion
• Speicherabbild des Prozesses

Debugger können diese Informationen bearbeiten und erlauben es, den Fehler auf der Instruktionsoder Quellcode-Ebene zu lokalisieren. Trotzdem gibt ein Core-Dump nicht alle nötigen Informationen, um einen Fehler zu lokalisieren. Zum Beispiel kann der Kontroll.uss bis zum Auftreten des Fehlers nicht reproduziert werden. Einige Fehler können außerdem ohne den kompletten Kontroll.uss nicht rekonstruiert werden. Eine detaillierte Beschreibungüber die Core-Dump Dateien kann in [Ric04] gefunden werden.