DOOM: Absturz auf echter Hardware nach 2,5 Jahren realem Dauerbetrieb bestätigt

 (lenowo.org)
4 Punkte von GN⁺ 2025-09-18 | 1 Kommentare | Auf WhatsApp teilen
  • Bestätigt wurde ein Spielabsturz durch einen Variablen-Overflow in der DOOM-Engine
  • In einer realen Nutzungsumgebung wurde ein Experiment mit 2,5 Jahren DOOM-Dauerbetrieb durchgeführt
  • Da der Variablenwert kontinuierlich anstieg, erreichte er schließlich den Overflow-Punkt, woraufhin das Spiel zum erwarteten Zeitpunkt beendet wurde
  • Das Experiment lief in einer Umgebung für langfristigen automatischen Betrieb mit einem PDA und einer DIY-USV
  • Dieser Test belegt, dass ein theoretisches Problem auch in der Praxis tatsächlich auftreten kann

Hintergrund und Motivation des Experiments

  • Vor etwa zweieinhalb Jahren wurde beim Lesen eines Artikels über Struktur und Funktionsweise der DOOM-Engine festgestellt, dass eine Variable zur Nachverfolgung der Demo-Ausführung bei jedem Start einer Demo weiter erhöht wird
  • Diese Variable wird zwar mit dem vorherigen Wert verglichen, doch durch die wiederholte Erhöhung besteht letztlich ein inhärentes Overflow-Risiko
  • In einer normalen Nutzungsumgebung ist es schwer, diesen Overflow-Punkt zu erreichen, doch es wurde beschlossen, durch ein eigenes Experiment zu prüfen, wie lange es tatsächlich dauert

Methode und Ablauf des Experiments

  • Durch eine einfache Berechnung wurde geschätzt, dass bis zum Auftreten des Overflows etwa 2,5 Jahre Laufzeit erforderlich sind
  • Zur tatsächlichen Überprüfung wurde DOOM auf einem PDA installiert und über eine DIY-USV mit 18650-Akkus mit Strom versorgt
  • Das Gerät wurde an den USB-Port eines Routers angeschlossen, um dauerhaft mit 5 V versorgt zu werden
  • Anschließend wurde das System so eingerichtet, dass es in einer automatischen Ladeumgebung kontinuierlich läuft, und die meiste Zeit sich selbst überlassen

Auftreten des Absturzes und Ergebnis

  • Rund zweieinhalb Jahre nach Beginn des Experiments erschien auf dem Bildschirm des Geräts eine Popup-Benachrichtigung
  • DOOM wechselte wie erwartet in einen Zustand eines harten Absturzes durch Overflow
  • Das Ergebnis des Experiments belegt, dass ein Spielabbruch durch Variablen-Overflow auch auf echter Hardware und in einer realen Softwareumgebung tatsächlich auftreten kann

Fazit und Implikationen

  • Es wird betont, dass in der Programmierung auf Variablen geachtet werden muss, die sich über lange Zeit akkumulieren und weiter ansteigen
  • Experimentell wurde bestätigt, dass ein Overflow-Problem, das nur theoretisch möglich schien, in der Realität tatsächlich ausbrechen kann
  • Es schärft das Bewusstsein für versteckte Fehler in Legacy-Code oder in Software, die über lange Zeit läuft

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-18
Hacker-News-Kommentare

  • Als ich vor etwa einem Jahr das Timersystem von Crash Bandicoot untersucht habe, fiel mir auf, dass in Crash 3 ein Wert vom Typ int32 ständig weiter hochzählt; zurückgesetzt wird er nur, wenn man stirbt. Lässt man das Spiel 2,26 Jahre lang laufen, kommt es zu einem Overflow. Dann wird die Zeit „negativ“ und das Spiel geht auf mehrere lustige Arten kaputt. Dazu habe ich ein Video gemacht: YouTube-Link

    • In Final Fantasy 9 muss man, um eine bestimmte Waffe zu erhalten, innerhalb von 12 Stunden (in der europäischen Version 10 Stunden) ein Gebiet im späteren Spielverlauf erreichen. Wegen eines Bugs kann man sie aber auch bekommen, wenn man das Spiel zwei Jahre lang laufen lässt, bis der Timer überläuft. Man kann also ganz entspannt warten und erreicht trotzdem sein Ziel. Link mit ausführlicher Erklärung

    • Erstaunlich, dass du in deinem Video nicht ein einziges Wortspiel mit „crash“ gemacht hast. Man hätte sogar einen Freeze als Crash bezeichnen können, ein bisschen schade.

    • Ich frage mich, ob es üblich ist, für die Verfolgung von Timern standardmäßig signed integers zu verwenden. Mit unsigned würde sich die Zeit bis zum Overflow doch verdoppeln; ich frage mich, warum man sich so entschieden hat.

    • Ich glaube, viele Spiele waren so aufgebaut. SotN hat auch einen globalen Timer. Auf 32-Bit-Systemen sah man wohl keinen Grund, extra den Ablauf von mehreren Jahren für ein Spiel zu testen, das ohnehin nur ein paar Monate bis höchstens ein paar Jahre genutzt werden würde. Damals konnte sich wohl niemand vorstellen, dass die eigene Software gehackt, analysiert und reverse-engineered werden würde. Wir berücksichtigen so etwas beim normalen Programmieren ja auch nicht groß.

    • Das ist der wahre Time-Twister-Unlock.

  • Das ist so eine Situation, in der man wirklich das Gefühl hat, dass das Spiel unspielbar wird. Hoffentlich fixt das jemand. Doom ist wirklich ein großartiges Spiel, und ich kehre alle paar Jahre immer wieder dazu zurück. Das Reboot von 2016 hat mir auch Spaß gemacht, aber die späteren Titel waren persönlich nicht so mein Fall.

    • Es gibt eine Community für Leute, die Gameplay im klassischen Doom-Stil bevorzugen: r/boomershooters

    • Geht mir genauso. Das Metroidvania-Design und die Hub-Struktur der neueren Titel vermitteln mir nicht mehr dieses alte Gefühl. Dieses einfache Vorankommen – laufen, Gegner erledigen, Geheimnisse finden und zum nächsten Level weitergehen – fühlt sich für mich besser an.

    • Sehe ich genauso, besonders den Brutality-Modus mag ich sehr.

    • Interessante Tatsache: Doom gehört jetzt zusammen mit Quake, StarCraft, WarCraft, Overwatch, allen Adventure-Spielen von Infocom und Sierra sowie Halo Microsoft. Microsoft wollte seit 1996 die meisten PC-Spiel-IP besitzen und hat dieses Ziel damit fast erreicht.

    • Der Titel von 2016 ist der beste Singleplayer-FPS, den ich je gespielt habe. Das Einzige, das für mich in derselben Liga spielt, ist Titan Fall 2.

  • Ich frage mich, ob es in Hardware eine Funktion gibt, die Overflow abfängt. Ich habe einen Artikel über die Funktionsweise der Doom-Engine gelesen und dort gesehen, dass eine Variable zur Verfolgung von Demos auch dann weiter hochzählt, wenn die nächste Demo startet. Diese Variable wird mit einer zweiten verglichen, die den vorherigen Wert speichert. Ich frage mich, warum das eigentliche Spiel dann abgestürzt ist.

    • In C ist signed overflow undefined behavior, deshalb ist das Ergebnis nicht vorhersagbar. Da es hier aber offenbar plattform- und compilerunabhängig immer gleich passiert, scheint das nicht die Ursache zu sein. Laut dem Artikel (TFA) wird diese Variable mit ihrem vorherigen Wert verglichen, und der Code war offenbar nicht darauf ausgelegt, dass new < old eintreten könnte. Dadurch können leicht Bugs wie Stack-Korruption entstehen. C führt ja auch klaglos undefined behavior aus, wenn zum Beispiel eine Funktion ohne return in einen Pfad gerät, in dem sie eigentlich einen Wert zurückgeben müsste.

  • Man sollte dankbar sein, dass die Ursache des Bugs schon bekannt war. Sonst hätte man vielleicht erst nach 2,5 Jahren gemerkt: „Verdammt, ich habe vergessen, das Debug-Log einzuschalten.“

  • DOOM ist vor Windows CE abgestürzt.

    • Ich bin fast noch mehr beeindruckt davon, dass eine Anwendung 2,5 Jahre lang auf einem PDA durchgelaufen ist. Ich bezweifle stark, dass so etwas heute auf moderner Hardware ohne unterbrochene Internetverbindung noch möglich wäre.

    • Wirklich eine beeindruckende Leistung.

  • Die Seite scheint wegen zu vieler Zugriffe down zu sein, daher hier ein archive.org-Link: archive.org-Speicherstand. Leider wurde das Format der Seite nicht vollständig archiviert, aber der Text ist noch da.

  • 2038 wird wohl ein interessantes Jahr.

    • Viele übersehen das NTP-Problem von 2036. Dann beginnt die eigentliche Party.

    • 2038 fühlt sich inzwischen viel näher an als Y2K damals.

    • Es bleiben noch 13 Jahre, um auf 64-Bit-int upzugraden oder time_t auf den Typ long long umzustellen. Viele Embedded-Geräte und eingestellte proprietäre Systeme werden besondere Aufmerksamkeit brauchen. Im OpenFirmware meines früheren SunServer 600MP gab es dasselbe Problem. Zum Glück ist das für mich heute kein Thema mehr.

    • Dieses Problem zu lösen, ist mein Ruhestandsplan.

  • Tests auf diesem Niveau würde keiner der Tester machen, die ich kenne. In dem System, an dem ich arbeite, musste ich erst gestern mehr als fünfmal warten, um die Fehlerbehandlung nach einem 30-Sekunden-Timeout zu überprüfen, und das war schon extrem nervig.

  • Früher gab es in Windows NT 4 einen ähnlichen Bug. Es ging um einen hochpräzisen Zähler zur Messung der System-Uptime. Vor Service Pack 3 (oder 2) ließ ich das System deshalb jeden Monat am 1. per Scheduler neu starten. Sonst stürzte es nach etwa 42 Tagen Uptime ab. Nicht einmal Microsoft ging also davon aus, dass ein Server-OS sehr lange am Stück laufen würde.

    • Meinst du vielleicht das Problem, das in diesem Link erwähnt wird? Oder gab es bei NT 4 noch einen separaten Bug?

  • Noch einmal großes Lob an das Team von id Software. Wäre das heute auf übliche Weise entwickelt worden, wäre es wahrscheinlich schon vor Ablauf von zwei Jahren an Speicherfragmentierung oder Memory Leaks gestorben.