Computerabsturz
aus Wikipedia, der freien Enzyklopädie
Ein Absturz bei einem Computer bezeichnet den Ausfall eines Programmes oder des gesamten Betriebssystems in Folge eines Programmierfehlers, einer Inkompatibilität oder (selten) eines Hardwarefehlers.
Die häufigste Form von Abstürzen ist der so genannte Pufferüberlauf, bei dem eine Variable größer wird, als der im Programm für sie vorgesehene Platz. Eng damit verwandt sind Fehler durch nicht erfüllte Erwartungen an die Werte der Variablen, etwa bezüglich der Umwandelbarkeit in andere Datentypen oder Zerlegungsmöglichkeiten durch Trennzeichen (siehe Validierung). Ein anderer sehr häufig anzutreffender Fehlertyp ist die Schutzverletzung (engl. „Protection Fault“, „Segmentation Fault“ oder „Segmentation Violation“, in einigen Betriebssystemen auch „Allgemeine Schutzverletzung“, „General Protection Fault“ genannt), ausgelöst, wenn ein Programm versucht auf Arbeitsspeicher zuzugreifen, der dem Programm nicht „gehört“. Das ist meist darauf zurückzuführen, dass ein Zeiger auf eine falsche Speicheradresse zeigt, häufig zum Beispiel auf Null.
Eine weitere Form mit anderem Ablauf ist das so genannte „Aufhängen“ eines Programms, bei dem das Programm scheinbar nicht weiterarbeitet. Das kann auf zwei Arten geschehen: das Programm „klemmt“ (→ Verklemmung) und tut nichts. Oder das Programm läuft in einer Endlosschleife, weil eine Abbruchbedingung niemals erfüllt wird.
Eine sehr seltene Form von Abstürzen sind durch Defekte in der Hardware bedingt, in denen Daten so verändert werden, dass diese zu einem Absturz führen.
[Bearbeiten] „Abstürze sind normal“
Aufgrund der Verbreitung von relativ häufig abstürzenden Computerprogrammen im Heimbereich, insbesondere die MS-DOS-basierenden Microsoft Windows-Versionen wie Microsoft Windows 95 oder Microsoft Windows 98, entstand in der Allgemeinheit der Eindruck, dass Abstürze unvermeidlich sind. Tatsächlich ist es aber auf vielen Ebenen möglich, solche Fehler zu einem großen Teil zu vermeiden: durch das Betriebssystem, die verwendete Programmiersprache oder deren Compiler, durch die Laufzeitumgebung und vor allem durch die Umsicht des Programmierers. Hierfür gibt es einige hilfreiche Regeln, wie etwa die Umwandelbarkeit von Daten vor dem Versuch zu prüfen (und idealerweise frühzeitig sicherzustellen) und Variablen, die größer als der Puffer sind, nicht anzunehmen. Viele dieser Aufgaben lassen sich sogar automatisieren.
Allerdings ist es nicht möglich, Abstürze völlig auszuschließen, da sich das Verhalten eines Programmes nicht für alle möglichen Fälle vorhersagen lässt (dies ginge nur durch das „Durchprobieren“ aller Fälle - und davon gibt es im Allgemeinen unendlich viele. Siehe Verifikation). Insbesondere ist das „Aufhängen“ eines Programms nicht mit analytischen Methoden vorherzusagen (siehe Halteproblem). Es wäre aber durchaus möglich, Software sehr viel stabiler zu gestalten, als sie das heute zumeist ist. Das erfordert allerdings langwierige Tests und Analysen, die meist als zu teuer empfunden werden (bei kommerzieller Software geht es dabei um bezahlte Arbeitsstunden, bei Freier Software ist das Problem eher der persönliche Zeitaufwand, und die Tatsache, dass solche Tests nicht sehr aufregend sind). Eine weitere Möglichkeit ist der Einsatz von Software der künstlichen Intelligenz (KI).
So wird häufig Software von fragwürdiger Qualität auf den Markt gebracht, was oft gut geht, gerade weil der Anwender gelernt hat, die Fehler als „normal“ zu akzeptieren.
[Bearbeiten] Absturz als Begriff im Zusammenhang mit Computer-Software
Es wird erzählt, dass die äußerst gebräuchliche Redewendung „mein Programm ist abgestürzt“ in der Zeit der Lochkartenverarbeitung geprägt wurde. Programme wurden in Form von kleinen Holzkästen mit Stapeln von Lochkarten mit den fortlaufenden Befehlen eines Programms am Abend auf ein kleines Förderband abgestellt, damit der Computer über Nacht (oder auch im Laufe des Tages) dieses Programm (neben vielen anderen) der Lochkartenleseeinheit und damit der Verarbeitung durch den Computer zuführen konnte. Das Programm wurde dann eingelesen, ausgeführt und die Resultate (in dieser Zeit waren Programme meist komplexe Berechnungen jedweder Art) wiederum auf Lochkarten ausgegeben.
Kam es nun zu Komplikationen im Ablauf, sei es, dass der Lochkartenleser den Stapel nicht fehlerfrei einlesen oder ausgeben konnte, sei es, dass das Programm durch fehlerhafte Programmierung oder Endlosschleifen zuviele Daten ausgab, dann war es nicht selten, dass der Kasten vom Ausgabe-Förderband fiel und alle Lochkarten ungeordnet auf dem Boden verstreut wurden. Damit war das Programm „abgestürzt“ und der Autor hatte am nächsten Tag einen Haufen Arbeit vor sich, die Lochkarten wieder neu zu sortieren.
