- 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
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“
In solchen Fällen dachte ich meist an zufällige Bit-Flips oder defekte Hardware
Er ist zwar etwas teurer, löst aber fast all diese Probleme. Einige Consumer-Mainboards unterstützen ECC bereits
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
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
AMD bietet bei Consumer-CPUs immerhin „teilweise Unterstützung“ für ECC, Intel erlaubt es hingegen nur in der Workstation-Klasse
Ob er dadurch aber zuverlässiger ist als DDR4 ohne ECC, ist nicht sicher
Wenn möglich, würde ich gern ein Notebook mit ECC verwenden
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.SetCrashOutputwurden Crash-Stacks von Goroutinen gesammelt und so Hunderte Bugs gefundenEinige 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
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
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
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
Auch memory_test.rs im Mozilla-Quellcode scheint so etwas zu tun
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
Beim Beenden wird viel Speicher freigegeben, daher treten Bit-Flips dann leichter zutage
Um die Ursache zu prüfen, wäre ein Speichertest sinnvoll
about:crasheszu teilenEs 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