Ablaufüberwachung objektorientierter Programme
Description
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 „Testmethoden" bei Communication Mobile Networks in Berlin leitet.
More details
Content
2 - Definitionsverzeichnis [Seite 14]
3 - Algorithmenverzeichnis [Seite 16]
4 - Abbildungsverzeichnis [Seite 18]
5 - Tabellenverzeichnis [Seite 22]
6 - Kapitel 1 Einleitung [Seite 24]
7 - Kapitel 2 Aktueller Stand der Software-Fehleranalyse [Seite 28]
7.1 - 2.1 Fehler [Seite 28]
7.2 - 2.2 Existierende Techniken [Seite 29]
7.3 - 2.3 Beispiel einer Fehleranalyse [Seite 30]
7.4 - 2.4 Problembeschreibung [Seite 32]
7.5 - 2.5 Verwandte Arbeiten [Seite 34]
7.5.1 - 2.5.1 Program-Profiling [Seite 34]
7.5.2 - 2.5.2 Program-Tracing [Seite 37]
7.5.3 - 2.5.3 Werkzeuge für die Fehlersuche [Seite 38]
7.6 - 2.6 Zusammenfassung [Seite 39]
8 - Kapitel 3 Graphentheoretische Grundlagen [Seite 42]
8.1 - 3.1 Grundbegriffe [Seite 42]
8.1.1 - 3.1.1 Allgemeine Graphen [Seite 42]
8.1.2 - 3.1.2 Wege: Definitionen und elementare Eigenschaften [Seite 43]
8.1.3 - 3.1.3 Erreichbarkeit und Zusammenhang [Seite 45]
8.1.4 - 3.1.4 Klassifizierung von Zusammenhangskomponenten [Seite 46]
8.1.5 - 3.1.5 Abgeleitete Graphen [Seite 47]
8.2 - 3.2 Die Standard-a-Zerlegung [Seite 49]
8.2.1 - 3.2.1 Klassen geschlossener a-Wege und Kantenzerlegungen [Seite 49]
8.2.2 - 3.2.2 Die Standard-a-Zerlegung allgemeiner Graphen [Seite 50]
9 - Kapitel 4 Ablaufgraphen von Programmen [Seite 54]
9.1 - 4.1 Überblick [Seite 54]
9.2 - 4.2 Ablaufgraphen prozeduraler Sprachen [Seite 54]
9.3 - 4.3 Ablaufgraphen objektorientierter Sprachen [Seite 56]
9.4 - 4.4 Fehlerbehandlung mit Ausnahmen in objektorientierten Sprachen [Seite 56]
9.5 - 4.5 Definitionen [Seite 58]
9.6 - 4.6 Format einer Java-Class-Datei [Seite 59]
9.7 - 4.7 Java-Bytecode [Seite 62]
9.8 - 4.8 Instrumentierung des Codes [Seite 66]
10 - Kapitel 5 Rekonstruieren von Abläufen in einem Ablaufgraphen [Seite 68]
10.1 - 5.1 Algorithmus zum Auffinden der Ereignisknoten SETEVENTS [Seite 68]
10.2 - 5.2 Markieren der Bögen [Seite 71]
10.3 - 5.3 Rekonstruieren von Abläufen (Algorithmus RECONSTRUCTFLOW) [Seite 73]
10.4 - 5.4 Beweis des Rekonstruierungsverfahrens [Seite 74]
10.5 - 5.5 Verheftungsknoten als Ereignisknoten [Seite 76]
10.6 - 5.6 Modifizierung des SETEVENTS Algorithmus [Seite 81]
10.7 - 5.7 Beispiel einer Ablaufrekonstruktion [Seite 84]
10.7.1 - 5.7.1 Auffinden der Ereignisknoten [Seite 84]
10.7.2 - 5.7.2 Markieren der Bögen [Seite 89]
10.7.3 - 5.7.3 Rekonstruieren der Abläufe [Seite 89]
10.8 - 5.8 Effizienzbetrachtungen des Algorithmus SETEVENTS [Seite 90]
10.9 - 5.9 Effizienzbetrachtungen des Algorithmus RECONSTRUCTFLOW [Seite 91]
11 - Kapitel 6 Analyse der Optimalität der Menge von Ereignisknoten [Seite 94]
11.1 - 6.1 Formalisierung der Minimalitäts- und Optimalitätskriterien [Seite 94]
11.2 - 6.2 Vergleich des SETEVENTS Algorithmus mit dem Knuth-Stevenson Algorithmus [Seite 97]
11.3 - 6.3 Kombinieren des Algorithmus mit dem Knuth-Stevenson Algorithmus [Seite 99]
11.4 - 6.4 Zerlegen der starken Zusammenhangskomponenten [Seite 104]
11.5 - 6.5 Hierarchie der Algorithmen zum Finden der Überwachungsmenge der Knoten [Seite 110]
11.6 - 6.6 Häufigkeitsanalyse und Wahrscheinlichkeitsanalyse [Seite 112]
12 - Kapitel 7 Ablaufrekonstruktion objektorientierter Programme [Seite 120]
12.1 - 7.1 Auffinden und Platzieren von Überwachungspunkten in einem Programm [Seite 120]
12.2 - 7.2 Protokollierung eines Ablaufes [Seite 121]
12.3 - 7.3 Rekonstruieren eines Ablaufes in einem objektorientierten Programm [Seite 122]
12.3.1 - 7.3.1 Ablauf innerhalb einer Methode [Seite 122]
12.3.2 - 7.3.2 Algorithmus zur Rekonstruktion eines Ablaufs im kompletten Programm [Seite 122]
12.3.3 - 7.3.3 Beispiel einer Rekonstruktion eines Objektorientierten Programms [Seite 128]
12.3.4 - 7.3.4 Erweiterungen des Algorithmus zum Rekonstruieren eines Ablaufes im kompletten Programm [Seite 134]
13 - Kapitel 8 Überwachungsagent für Java-basierte Anwendungen [Seite 146]
13.1 - 8.1 Beschreibung [Seite 146]
13.1.1 - 8.1.1 Phase 1: Bestimmen von Überwachungspunkten eines Programms [Seite 147]
13.1.2 - 8.1.2 Phase 2: Aktivieren der Überwachungspunkte und Protokollieren der Ereignisse [Seite 147]
13.1.3 - 8.1.3 Phase 3: Rekonstruieren der Abläufe [Seite 149]
13.2 - 8.2 Beispiele [Seite 149]
13.3 - 8.3 Verifikation der Algorthmen [Seite 151]
14 - Kapitel 9 Zusammenfassung und Ausblick [Seite 156]
15 - A Abgeleitete Graphen [Seite 158]
16 - B gprof -Beispiel [Seite 160]
17 - C strace-Beispiel [Seite 161]
18 - D Byte-Code der main-Methode [Seite 162]
19 - Literatur [Seite 164]
20 - Index [Seite 168]
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.
