7 Hilfen zur Fehleranalyse

Verfügbarkeit

Die in diesem Kapitel beschriebenen Hilfen zur Fehleranalyse stehen für die DM Versionen A.05.01.g3 und A.05.01.h sowie ab A.05.02.e zur Verfügung.

7.1 Überblick

Die hier beschriebenen Hilfsmittel haben das Ziel, Entwickler in besonderen Situationen, wie Interpreter-Fehlermeldungen, Abstürzen1 einer Anwendung oder Assfail (Fatal Error) Meldungen durch zusätzliche Informationen bei der Analyse und Einordnung von Fehlern zu unterstützen. Die folgende Tabelle enthält eine grobe Klassifizierung möglicher Fehler nach typischen Fehlerstellen und ihren wahrscheinlichen bzw. möglichen Auswirkungen. Die Auswirkung, dass ein Fehler unentdeckt bleibt, zu einer veränderten oder fehlerhaften Funktionalität führt oder in eine andere Komponente hineingetragen wird, ist in der Tabelle nicht explizit erwähnt.

Fehlerstelle	Beschreibung	Auswirkung
Regelcode	Fehler im Regelcode einer IDM-Anwendung, z.B. ungültige Zugriffe auf ein Attribut oder Objekt, Typfehler oder uninitialisierte Werte.	*** Eval Error im Log- oder Tracefile [E: …] oder [W: …] Meldungen, YE-Fehlercodes im Tracefile
Applikationsfunktion	Verschiedene Fehlerarten, z.B. Zugriffsverletzung, beschädigte Speicherverwaltung, die sich in letzter Konsequenz unter Umständen aber erst bei der Regelverarbeitung oder in der IDM-Bibliothek zeigen.	eventuell Absturz
IDM-Bibliothek	Innerhalb des IDM sind fehlerhafte Zustände normalerweise durch eine Assertion abgesichert. Allerdings kann sich ein Fehler durchaus auf die Regelverarbeitung auswirken oder wie ein Applikationsfehler zeigen.	FATAL ERROR im Log- oder Tracefile [E: …] oder [W: …] Meldungen im Tracefile
Externe Funktionen	Externe, vom IDM unabhängige Funktionen, z.B. in einem anderen Thread oder einer anderen Bibliothek, kann Fehler enthalten und diese z.B. durch Überschreiben von Speicher oder fehlerhafte Synchronisierung in andere Bereiche hineintragen.	z.B. Absturz

Im Folgenden werden die Erweiterungen zur Fehleranalyse und ihr Einsatzzweck erläutert.

Anmerkungen

Grundsätzlich sollen die Erweiterungen keinen Debugger oder ein Werkzeug wie Dr. Watson unter Microsoft Windows ersetzen. Sie sind als Ergänzung zu verstehen, um sinnvolle Informationen zu liefern, die von den genannten Werkzeugen nicht geliefert werden.
Wenn zuvor bereits schwerwiegende Fehler aufgetreten sind, kann die Richtigkeit der ausgegebenen Informationen nicht vollständig garantiert werden.

7.1.1 Safety-Tracing

Um den Nutzen des Tracing im IDM auch auf Situationen auszudehnen, in denen ein Fehler erst nach längerer Laufzeit einer Anwendung auftritt, kann der Safety-Modus des Tracing benutzt werden.

Normalerweise führt das ständige Mitlaufen des Tracing zu einer deutlichen Performanzeinbuße und einer sehr großen, unhandlichen Tracedatei. Im Safety-Modus erfolgt das Tracing in einen Ringpuffer mit begrenzter Zeilenzahl und Zeilenlänge, der im Arbeitsspeicher gehalten wird. Erst beim Beenden einer Anwendung oder bei einem Fehlerereignis wird dieser Puffer in die Tracedatei geschrieben.

Weitere Informationen zum Safety-Tracing sind bei den Startoptionen ‑IDMstrace, ‑IDMstracefile und ‑IDMstraceopts im Kapitel „Startoptionen“ sowie im Kapitel „Safety-Tracing“ zu finden.

7.1.2 Dumpstate

Bei Abstürzen, einem FATAL ERROR oder einer Error in Eval Meldung hat man ohne Tracing bei Anwendungen, die Binärdateien und die IDM-Laufzeitblibliothek nutzen, nur wenige Anhaltspunkte. Der Dumpstate stellt eine Zustandsinformation von IDM-Spezifika dar. Dazu gehören die Aufrufliste (Callstack), gemerkte Fehlercodes (Errorstack), Ereignisse sowie Hinweise über die Anzahl von IDM-Objekten und die Speichernutzung durch den IDM.

Primäres Ziel ist es, in einer Fehlersituation möglichst viele Information auszugeben, um so eine Bewertung des Fehlers zu ermöglich und die Ursachenforschung zu erleichtern. Es können nur Informationen gesammelt werden, die dem IDM bekannt sind, keine Informationen über Applikations- oder Fremdfunktionen. Das Schreiben des Dumpstate kann auch programmatisch über die Regelsprache oder eine DM-Schnittstellenfunktion erreicht werden.

Wichtiger Hinweis

Sicherheitsrelevante Informationen, z.B. Passwörter, die in ein Login-Fenster eingegeben werden, sollten nach ihrer Verwendung von der Anwendung gelöscht werden, damit sie nicht über einen Dumpstate ausgegeben und dadurch zugänglich gemacht werden.

Weitere Informationen zur Dumpstate-Ausgabe sind bei den Startoptionen ‑IDMcallstack, ‑IDMdumpstate und ‑IDMdumpstateseverity im Kapitel „Startoptionen“ sowie im Kapitel „Dumpstate (Zustandsinformationen)“ zu finden.

7.2 Exception-Catcher

Um bei einem Absturz das Safety-Tracing wie auch den Dumpstate herausschreiben zu können, wird ein globaler Exception-Catcher für eine Anwendung angemeldet. Der IDM installiert im Bootstrap einen globalen Exception-Catcher (für Structured Exceptions unter Microsoft Windows, signal-Handler unter Unix) für abfangbare Ausnahmen.

Beim Auftreten einer Exception gibt der IDM einen FATAL ERROR mit der Exception-Nummer aus. Wenn notwendig und eingestellt, werden Dumpstate und Safety-Tracefile geschrieben. Der Exception-Catcher reicht die Exception dann wie gewohnt weiter, um so die weitere Behandlung durch das Betriebssystem (core dump unter Unix/Linux oder das Schreiben einer Dump-Datei unter Microsoft Windows durch Dr. Watson) zu ermöglichen.

Hinweis

Beim Einrichten eigener Exception-Handler ist zu beachten, dass diese eine Exception weiterreichen.

Die Einrichtung eines Exception-Catcher kann mit der Startoption ‑IDMcatchexceptions (siehe Kapitel „Startoptionen“) unterbunden werden.