t-ota - Digest - O2K-Komplex

O2K-Komplex

From: Thomas Rehm <Th.Rehm@T-Online.de>
Newsgroups: t-online.talk.allgemein
Subject: O2K-Problem
Date: Sun, 31 Mar 2002 18:02:42 +0100
Message-ID: <3CA74132.1484@T-Online.de>


Hallo!

Ich weiß nicht, welche Newsgroup für mein Problem richtig ist, daher
wähle ich einfach mal diese allgemeine Gruppe - ggf. kann das T-Online-
Team ein Follow-Up in die richtige Gruppe setzen.

Soeben las ich von den Auswirkungen eines anscheinend wenig bekannten
Phänomens, dem O2K-Komplex. Hat davon schon mal jemand gehört? Ich
nicht.
Außer dem Y2K-Bug, welches sich glücklicherweise als harmlos heraus
stellte und dem Y3K-Problem, welches uns nicht mehr zu interessieren
braucht (die Enkel werden´s schon richten), hatte ich von dem erwähnten
O2K-Komplex noch nie was gehört.

Offensichtlich hofft man, durch Stillschweigen und Nichterwähnung
ähnlich
billig davon zu kommen wie bei dem Y2K-Problem, bei dem ja ein recht
großer und unnötiger Aufwand getrieben wurde (wie man allerdings erst
im Nachhinein wusste).
Jedoch könnte das diesmal in´s Auge gehen, wenn ich der gewöhnlich gut
informierten Quelle glauben soll.

Bei dem O2K-Komplex handelt es sich um einen Buffer-Underrun in der
Windows-Bibliothek LIRPA.DLL (das sog. "Ostermodul") bei der Berechnung
des Datum für den (beweglichen) Feiertag Ostern. Die Besonderheit des
diesjährigen Ostertermins ist, dass der 1. Osterfeiertag auf den letzten
Tag des ersten Quartals und der 2. Osterfeiertag gleichzeitig auf den 1.
April fällt.
Auch wenn diese Tatsache selbst zunächst als harmlos erscheint, könnten
die Folgen doch gravierend sein. Die technischen Details habe ich zwar
im Einzelnen nicht ganz verstanden, aber es scheint bei der Berechung
des 2. Osterfeiertages in 2002 eine unendliche Iteration aufgerufen zu
werden, welche im (objektorientierten) Modul LIRPA1.DLL eine virtuelle
Methode (ein Unterprogramm) aufruft, welches gleichzeitig in sich selbst
verzweigt und infinit iteriert.
Die Folge sind mehrere Gigabyte infinitesimal reduzierter Bits (wenn ich
das richtig verstanden habe, sind das in sich zusammen gefallene Bits,
ähnlich wie Materie in einem schwarzen Loch in sich zusammenfällt),
welche zu lokalen Komprimierungen des Arbeitsspeichers führen.
Kurzum, es entstehen digitale Leerstellen, also ein Vakuum, welche
aufgrund des umgebenden Luftdrucks zu einer Implosion des Arbeits-
speichers führen kann, wenn der Chip nicht ausreichend stabil gebaut
ist.
Wenn der Chip erst einmal implodiert ist, so ist der Datenverlust
irreversibel - abgesehen von den Hardwareschäden, die unabsehbar sind
(eine Implosion könnte - ähnlich einer Explosion - die Innereien eines
PCs völlig verwüsten).

Da dieses Thema offensichtlich totgeschwiegen wurde, gibt es natürlich
weder Untersuchungen zu diesem Thema noch über eventuelle Abhilfe-
maßnahmen.
Es heißt, das Verlagern der Datei LIRPA1.DLL in ein Unterverzeichnis
würde dem Problem abhelfen - von einem Löschen hingegen wird abgeraten.
Da ich jedoch im DLL-Verzeichnis meines Rechners keine LIRPA1.DLL fand,
muß ich annehmen, daß diese in der Windows-Version, die ich benutze,
einen anderen Namen hat.

Daher werde ich am Abend des 31. März das Datum meines Rechners auf den
2. April stellen in der Hoffnung, so dem möglicherweise fatalen Buffer-
Underrun im Ostermodul zu entgehen und kann nur jedem raten, es mir
gleich zu tun.

Ob auch Lunix-Rechner betroffen sind, kann ich nicht sagen. Daher kann
ich T-Online nur den Ratschlag geben, im Zweifelsfalle auf deren Server
das Datum 1.4.2002 mittels Shellscript zu überspringen.

mit betroffenen Grüßen,
Thomas.

-- 
In dubio chris rea.
Nach oben