2 Punkte von GN⁺ 2026-03-06 | 1 Kommentare | Auf WhatsApp teilen
  • Die Analyse von Firefox-Absturzberichten zeigt, dass Hardwarefehler durch Bit-Flips einen erheblichen Anteil aller Abstürze ausmachen
  • In der vergangenen Woche wurden unter rund 470.000 Absturzberichten etwa 25.000 Fälle als potenzielle Bit-Flip-Ereignisse erkannt
  • Es hat sich gezeigt, dass nicht Software-Bugs, sondern Hardwarefehler für bis zu 10–15 % der Abstürze verantwortlich sind
  • Das nach einem Absturz ausgeführte Speichertest-Tool prüft in weniger als 3 Sekunden höchstens 1 GiB, findet dabei aber tatsächlich viele Defekte
  • Diese Probleme betreffen alle Geräte wie PCs, Smartphones, Router und Drucker und machen die Grenzen der Zuverlässigkeit von Consumer-Hardware sichtbar

Firefox-Abstürze und die Erkennung von Bit-Flips

  • Es wurde ein Verfahren entwickelt, um Bit-Flips in Firefox-Absturzberichten zu erkennen; später wurde ein Speichertest-Tool ausgerollt, das nach einem Absturz automatisch auf echten Nutzergeräten ausgeführt wird
    • Das Tool läuft direkt nach einem Browser-Absturz auf dem Gerät des Nutzers und prüft auf Speicherfehler
  • Die Analyse der gesammelten Daten bestätigt, dass die Heuristik zur Bit-Flip-Erkennung wirksam ist und viele Abstürze auf defekten Speicher oder instabile Hardware zurückgehen

Statistische Ergebnisse

  • In der vergangenen Woche gingen rund 470.000 Absturzberichte ein; darin enthalten ist nur ein Teil aller Abstürze, da die Erfassung auf Opt-in basiert
    • Davon wurden etwa 25.000 Fälle (rund 5 %) als Abstürze mit möglichem Bit-Flip erkannt
    • Der tatsächliche Anteil ist eine konservative Schätzung; real könnte er mehr als doppelt so hoch sein
  • Von allen Firefox-Abstürzen gehen bis zu 10 % auf Hardwarefehler zurück; ohne Abstürze durch Ressourcenmangel wie Speicherauslastung sind es rund 15 %
    • Die Zahlen können etwas verzerrt sein, weil Nutzer mit defekter Hardware häufiger Abstürze erleben

Ergebnisse des Speichertests

  • Das Speichertest-Tool, das nach einem Absturz ausgeführt wird, prüft in weniger als 3 Sekunden bis zu 1 GiB Speicher, erkennt dabei jedoch tatsächlich viele Hardwaredefekte
    • Bei einem von zwei Abstürzen, die als Bit-Flip-Fälle eingeschätzt wurden, wurde ein realer Defekt bestätigt
  • Trotz des begrenzten Umfangs zeigt der Test eine hohe tatsächliche Fehlerrate

Auswirkungen auf Hardware insgesamt

  • Diese Probleme betreffen nicht nur Computer und Smartphones, sondern alle elektronischen Geräte wie Router und Drucker
    • Auch auf Geräten wie ARM-basierten MacBooks, bei denen der RAM im CPU-Paket verlötet ist, wurden viele Abstürze gemeldet
    • Ein Austausch des RAM ist bei solchen Geräten ohne Spezialausrüstung und erfahrene Techniker nicht möglich

Diskussionen in der Community und weitere Informationen

  • Einige Nutzer teilten Beispiele für defekten RAM und ihre Erfahrungen mit memtest86 und kritisierten mangelnde Qualitätskontrolle der Hersteller
  • Es wurde über die Notwendigkeit von ECC-RAM diskutiert; dabei wurde die Ansicht geäußert, dass schon SECDED ECC die Lebensdauer von Consumer-Geräten deutlich verlängern könnte
  • Es gibt zwar Forschung zu Speicherfehlern in Server-Umgebungen, jedoch wurde angemerkt, dass die Bedingungen in Consumer-Geräten anders sind und ein direkter Vergleich schwierig ist
  • Die Datenanalyse zeigte eine starke Korrelation zwischen Gerätealterung und der Häufigkeit von Speicherfehlern
  • Bit-Flips können nicht nur Abstürze verursachen, sondern auch zu dauerhaftem Datenverlust wie Dateisystembeschädigungen führen; deshalb wurde die Bedeutung von prüfsummenbasierten Dateisystemen hervorgehoben

Fazit

  • Es wird klar, dass ein erheblicher Anteil der Firefox-Abstürze nicht auf Softwarefehler, sondern auf Hardwareprobleme zurückgeht
  • Dadurch wird die Notwendigkeit von Speicherfehlererkennung und dem Einsatz von ECC in Consumer-Geräten besonders deutlich
  • Der Fall zeigt, dass die Sicherstellung von Hardwarezuverlässigkeit direkt mit einer höheren Softwarestabilität zusammenhängt

1 Kommentare

 
GN⁺ 2026-03-06
Hacker-News-Kommentare
  • Ich hatte das früher schon einmal auf HN erwähnt: Ein ehemaliger Kollege aus meiner ArenaNet-Zeit, Mike O’Brien (der Erfinder von battle.net), baute um 2004 ein Bit-Flip-Erkennungssystem in Guild Wars ein
    In jedem Frame (etwa 60 FPS) wurde zufälliger Speicher allokiert, mathematische Operationen darauf ausgeführt und das Ergebnis mit einer Referenztabelle verglichen; ungefähr 1 von 1000 Rechnern fiel dabei durch
    Die Ursachen waren meist übertaktete CPUs, falsche Speicher-Timings, unzureichende Stromversorgung oder mangelhafte Kühlung, und da das Spiel viel Außengelände renderte, überhitzten die Computer oft
    Später stellte sich heraus, dass auch Qualitätsprobleme bei günstigen Dell-Komponenten oder RowHammer-Angriffe mögliche Ursachen waren
    Ich schrieb dann Code, der bei einem fehlgeschlagenen Test den Browser öffnete und eine Seite anzeigte mit dem Hinweis, man solle „den Computerlüfter reinigen“

    • Als YouTube-Mobile-Entwickler sehe ich in den Crash-Reports des Codes, für den ich verantwortlich bin, Fälle, die überhaupt keinen Sinn ergeben
      In solchen Fällen dachte ich meist an zufällige Bit-Flips oder defekte Hardware
    • Ich verstehe nicht, warum ECC-Speicher immer noch nicht Standard ist
      Er ist zwar etwas teurer, löst aber fast all diese Probleme. Einige Consumer-Mainboards unterstützen ECC bereits
    • Guild Wars 1 war das Spiel meiner Kindheit
      Meine Eltern mochten es, weil es keine Monatsgebühr gab, und das 8-Skill-Build-System war wirklich genial
      Falls ein dritter Teil erscheint, hoffe ich auf noch mehr Freiheit beim Build-Ausdruck
    • Ich habe diese Geschichte früher schon im Blog Code of Honor gelesen
    • Dank eines ASRock-Mainboards konnte ich ECC-Speicher mit einem Threadripper 1950x verwenden
      Bei Overclocking-Tests konnte ich dank ECC feine Fehler erkennen, und seitdem vertraue ich Overclocking ohne ECC überhaupt nicht mehr
      Gerade bei DDR5 ist es schwierig, Stabilität sicherzustellen, und der Speicher ist hitzeempfindlich, daher halte ich Overclocking ohne ECC für unmöglich
  • ECC-Speicher hätte ab dem Zeitpunkt, an dem 1 GB überschritten wurde, Standard sein müssen
    Heute sind nutzlose RGB-LED-RAMs billig, während ECC teuer ist, und das frustriert mich

    • Schwerer als ECC selbst ist es, eine unterstützende CPU und ein passendes Mainboard zu bekommen
      AMD bietet bei Consumer-CPUs immerhin „teilweise Unterstützung“ für ECC, Intel erlaubt es hingegen nur in der Workstation-Klasse
    • DDR5 hat standardmäßig integrierte Fehlerkorrekturfunktionen
      Ob er dadurch aber zuverlässiger ist als DDR4 ohne ECC, ist nicht sicher
    • Ich denke, die eigentliche Ursache dieses Problems ist Intels Politik
    • In Laptops habe ich ECC-Speicher so gut wie nie gesehen
      Wenn möglich, würde ich gern ein Notebook mit ECC verwenden
    • ECC ist traditionell langsamer und komplexer und beseitigt Probleme nicht vollständig
      Aber in Server-Umgebungen mit stabiler Stromversorgung und Temperaturbedingungen verhindert es 99 % der Fehler
  • Das Go-Team hat ein telemetriebasiertes Crash-Reporting-System eingeführt
    Mit runtime.SetCrashOutput wurden Crash-Stacks von Goroutinen gesammelt und so Hunderte Bugs gefunden
    Einige Reports ließen sich jedoch nicht erklären, etwa durch Speicherbeschädigung oder CPU-Fehlverhalten
    Da die meisten Notebook-Nutzer Speicher ohne ECC verwenden, hielt man Hardwarefehler für wahrscheinlich

    • Bit-Flips betreffen auch den Code selbst, daher sind sogar Telemetrie-Ergebnisse schwer vertrauenswürdig
    • Wenn man den Reports CPU-Temperaturdaten hinzufügt, könnte man überhitzte Hardware aussortieren
    • Auch in iOS-Apps gab es gelegentlich unerklärliche Crashes, möglicherweise wegen Bit-Flips auf alten iPads
    • Ich versuche ebenfalls gerade, meinen Vorgesetzten davon zu überzeugen, Crash-zentrierte Telemetrie in Produktion einzuführen
  • Ich möchte auch den Bit-Flip-Fall im JuliaLang-Blog teilen

  • Die Behauptung „10 % der Firefox-Crashes gehen auf Hardwarefehler zurück“ wirkt etwas gewagt
    In Chromium-basierten Browsern treten solche Crashes nicht so häufig auf

    • Meine Intuition kann falsch sein
      Vielleicht ist Chrome stabiler, weil es bei den übrigen 90 % besser mit Software-Bugs umgehen kann
      Das könnte sogar bedeuten, dass die meisten Firefox-Crashes Softwareprobleme sind
    • Nur weil 10 % der Crashes so verursacht werden, heißt das nicht, dass das für alle Nutzer gleichermaßen gilt
    • Mein Firefox stürzt fast nie ab. Ich habe dutzende Tabs offen und lasse ihn wochenlang laufen, ohne Probleme
    • Nutzer mit schlechter Hardware schicken wahrscheinlich mehr zusätzliche Crashes
    • Ich habe seit Monaten keinen Firefox- oder Chrome-Crash mehr gesehen. Ich würde empfehlen, die Hardware einem Stresstest zu unterziehen
  • Ich habe einen Beitrag gesehen, in dem stand, man sei sich sicher, dass Bit-Flips die Ursache seien, aber es fehlt eine Erklärung, wie das erkannt wurde

    • Vermutlich ähnlich wie bei memtest86: Muster in den Speicher schreiben, wieder auslesen und vergleichen
      Auch memory_test.rs im Mozilla-Quellcode scheint so etwas zu tun
    • Tatsächlich wird erwähnt, dass „nach einem Browser-Crash auf dem PC des Nutzers ein Speichertest ausgeführt wird“
    • Letztlich haben sie Bit-Flips wohl nicht direkt erkannt, sondern eher Crashes infolge instabilen Speichers beobachtet
    • Ein typischer Fall ist ein Segfault durch einen Ein-Bit-Fehler, etwa wenn nur ein einziges Bit eines Pointers falsch ist
  • Ich habe einen neuen PC gekauft und den RAM auf 5800 MHz übertaktet, worauf Fedora seltsam einfror und Apps nicht mehr starteten
    Als ich memtest laufen ließ, erschienen schon nach zwei Minuten massenhaft rote Fehler, und nachdem ich den Takt auf 5200 gesenkt hatte, war das System stabil
    Dass ich so einen Beitrag genau jetzt auf der HN-Startseite sehe, ist perfektes Timing

  • Es überrascht mich, dass die Crash-Rate von Firefox höher ist als gedacht
    Ich habe seit Jahren ständig Crashes beim Beenden und sende jedes Mal einen Report ab
    Alle Erweiterungen sind WebExtensions, trotzdem tauchen verschiedenste Ursachen auf
    Firefox kann zwar mehrere Fenster und Tabs gut handhaben, aber bei der Stabilität gibt es Verbesserungsbedarf

    • Crashes beim Beenden können auch das Ergebnis von Speicherbeschädigung sein
      Beim Beenden wird viel Speicher freigegeben, daher treten Bit-Flips dann leichter zutage
      Um die Ursache zu prüfen, wäre ein Speichertest sinnvoll
    • Falls möglich, wird darum gebeten, den Report-Link aus about:crashes zu teilen
  • Es freut mich, dass tatsächlich jemand solche Daten sammelt
    Ich halte defekten Speicher für eines der am meisten unterschätzten Probleme im Computing
    Es wäre schön, dazu eine kurze Zusammenfassung im Stil eines technischen Whitepapers zu haben