Im Idealfall sollte ein Betriebssystem nach einem Programmabsturz dafür sorgen, daß es nicht zu Folgefehlern kommt, die einen kompletten Crash nach sich ziehen. Daß dies TOS nur selten gelingt, zeigt die Erfahrung. Durch einen kleinen Eingriff läßt sich die Stabilität des Systems nach einem Absturz erhöhen.

Doch zunächst sollte man sich Gedanken darüber machen, woran es denn liegen kann, daß nach einem abrupten Programmende häufig gar nichts mehr geht. Durch die Komplexität des GEM bedingt, ist die Wiederaufnahme des normalen Betriebs nach einem Absturz prinzipiell schwierig. Gerade in den TOS-Versionen ab TOS 1.04 wurde jedoch durch die Einführung des AES-Aufrufs wind_get eine Vorkehrung getroffen, die es dem GEM eher erlaubt, sich von den Folgen eines Absturzes zu erholen. Aber auch bei fehlerhaften TOS-Programmen beobachtet man, daß der Rechner nach einem Absturz oder spätestens nach dem Start des nächsten Programms eine Ruhepause einlegt, aus der man ihn nur durch Betätigung des Reset-Knopfes wieder erwecken kann. Schuld an diesem Verhalten sind häufig Systemvektoren, die von einem nicht residenten Programm verändert wurden und nach dessen Absturz ins Leere zeigen. Solange kein weiteres Programm gestartet wird, scheint alles im Lot zu sein, denn noch befindet sich der Code des ursprüngliches Programmes im Speicher. Wird nun aber ein neues Programm geladen, landet der Prozessor beim Sprung durch die Vektoren in einem Undefinierten Datenbereich, und der endgültige Absturz ist perfekt.

Resident oder nicht?

Somit wären also veränderte Vektoren als die eigentliche Ursache für viele System-Crashs ausgemacht. Das Verbiegen von Vektoren ist für die Funktion vieler Programme unvermeidlich, so daß es keinen Sinn macht, das Ändern von Systemvektoren prinzipiell zu unterlassen.

Aber dennoch: Diese Vektoren dürfen ausschließlich von residenten Programmen manipuliert werden, wobei das XBRA-Verfahren zu verwenden ist [1], Residente Programme verbleiben nach ihrer Beendigung im Speicher, so daß weiterhin definierter Code an der Einsprungadresse des Vektors steht.

Die eigentlichen Übeltäter sind somit die nicht residenten Programme, falls diese Vektoren verbiegen. Häufig geschieht dies lediglich dazu, beim Auftreten eines Bus- oder Adreßfehlers einen Absturz in Form von Bomben zu vermeiden und stattdessen eine entsprechende Meldung auszugeben, die den Anwender zwar beruhigen mag, aber das eigentliche Problem, nämlich den Programmfehler, nicht aus der Welt schafft.

Neben ungültigen Werten in den Exception-Vektoren, die ja nicht regelmäßig angesprungen werden, droht eine viel größere Gefahr dann, wenn ein Programm einen VBL-Slot belegt und abstürzt, ohne diesen wieder freigegeben zu haben. Da der Vertical Blank Interrupt regelmäßig auftritt, ist in solchen Fällen ein baldiger Absturz unvermeidlich. (Die Rechenkünstler unter den Lesern haben sicherlich schon ausgerechnet, daß es bis zum endgültigen Zusammenbruch bei einem Farbmonitor etwa 2.6x10'3 s länger dauert als bei Monochrom-Monitoren.)

Vektor-Check

Eigentlich liegt es auf der Hand, wie man dem geschilderten Problem zu Leibe rücken kann. Jedesmal dann, wenn ein Programm (auf welche Weise auch immer) beendet wird, müssen alle Systemvektoren und die Vektoren in der VBL-Queue überprüft werden. Zeigt ein Vektor in einen nicht mehr allozierten Bereich, liegt ein Fehler vor. Im Falle eines Eintrags in der VBL-Queue genügt es, diesen durch einen Null-Pointer zu löschen. Bei den restlichen Vektoren ist die Sachlage komplizierter, da diese ja von mehreren Programmen gleichzeitig benutzt werden können und man überdies nichts über deren ursprünglichen Wert aussagen kann. Hier ist man darauf angewiesen, daß alle vektorverbiegenden Programme das XBRA-Verfahren verwendet haben. Nur dann ist es möglich, den Vektor des unsanft beendeten Programms aus der Vektorkette auszuklinken, ohne daß andere Routinen davon beeinträchtig werden. Wurden Vektoren ohne Nutzung des XBRA-Mechanismus verbogen, bleibt lediglich die Möglichkeit, den ins Nirwana zeigenden Vektor vorsichtshalber auf einen RTE-Befehl umzulenken.

Natürlich muß man sich vor der Überprüfung der Systemvektoren vergewissern, daß ein Programm sich terminiert, ohne resident im Speicher zu verbleiben. Andernfalls wäre es natürlich falsch, verbogenene Vektoren, die in dieses Programm zeigen, zurückzusetzen. Nur bei nicht residenten Programmen ist ein Eingriff erlaubt.

CHECKIT

Die gestellten Forderungen erfüllt das Programm CHECKIT. Dabei ist die Systemvariable etv_term für unsere Anwendung sehr hilfreich. Dieser Vektor zeigt auf eine Routine, die nach der Beendigung jedes Programms angesprungen wird. Dies ist auch dann der Fall, wenn es sich um einen unvorhergesehenen Abbruch, beispielsweise durch einen Absturz, handelt.

Über den aktuellen Prozeß-Deskriptor läßt sich leicht feststellen, in welchem Speicherbereich TEXT, DATA und BSS-Segment dieses Programms lagen. Diese Informationen werden für die Entscheidung benötigt, ob ein Systemvektor in den Code- oder Datenbereich des Programms zeigt. Um welchen Programmtyp, also resident oder nicht resident, es sich handelt, erkennt CHECKIT anhand des letzten von diesem Programm abgesetzten GEMDOS-Aufrufs. Handelte es sich hierbei um PTERMRES, so bleibt der Programmcode resident im Speicher, und es ist nicht notwendig, irgendwelche Vektoren zu überprüfen. In allen anderen Fällen muß CHECKIT in Aktion treten.

Das hier vorgestellte Verfahren greift natürlich nur solange, wie ein Programm keine Vektoren in einen per MALLOC angeforderten Speicherblock legt. Prinzipiell wäre es zwar denkbar, auch bei MFREE-Aufrufen zu überprüfen, ob ein Vektor in den freigegebenen Speicherblock zeigt, aber leider benutzt das Desktop beim MFREE nach der Beendigung eines Programms nicht den GEMDOS-Vektor. Stattdessen wir direkt ins GEMDOS eingesprungen, so daß man hier nicht eingreifen kann Erst im MultiTOS wird sich dies ändern, da das Desktop dann lediglich noch eine GEM-Anwendung unter vielen darstellt, die für Systemaufrufe die TRAP-Vektoren benutzen muß.

Vektormanipulationen über das BIOS

Die genaue Funktionsweise von CHECKIT kann dem kommentierten Programm-Listing entnommen werden. Der Prozeß-Deskriptor läßt sich erst ab TOS 1.02 aus der _sysbase-Struktur entnehmen. Für TOS 1.00 muß man auf die inzwischen dokumentierte Adresse zurückgreifen, die sich im spanischen TOS von den restlichen länderspezifischen TOS-Versionen unterscheidet.

Daß CHECKIT die Installation der neuen Systemvektoren über die BIOS-Routine SETEXC erledigt und dazu nicht selber direkt auf die entsprechenden Adressen zugreift, hat übrigens einen guten Grund. Auf dem ST war es noch relativ sicher, TRAP-Vektoren durch direkten Zugriff auf die entsprechende Vektoradresse zu manipulieren, da diese Adresse konstant war. Bei anderen Prozessoren als dem 68000 sieht das jedoch anders aus. Hier kann der Beginn der Tabelle der Exception-Vektoren durch Manipulation des Vector-Base-Registers (VBR) an eine andere Stelle verlegt werden. Um sicherzugehen, daß man wirklich den gewünschten Vektor ändert, bleibt somit nur der Weg über das BIOS, das auch in zukünftigen TOS-Versionen, die das VBR nutzen könnten, den Vektor garantiert an die richtige Adresse schreibt.

Literatur:

[1] Jankowski, Rabich, Reschke, „Atari Profibuch ST-STE-TT", SYBEX-Verlag