'10 tot 15 procent van Firefox-crashes wordt door slechte hardware veroorzaakt'

Zo'n tien procent van alle Firefox-crashes komt van hardwareproblemen. Een ontwikkelaar van de browser zegt op basis van heuristische gegevens dat het dan gaat om bit-flips of soortgelijke fouten in het geheugen, bijvoorbeeld wanneer gebruikers te weinig of te oud ram hebben.

Dat schrijft Gabriele Svelto, een ontwikkelaar bij Mozilla. Hij schrijft op Mastodon heuristische gegevens over crashrapportages te hebben onderzocht. Gebruikers kunnen zo'n crashrapportage naar Mozilla sturen als Firefox crasht. Dat gebeurde 470.000 keer in een week, zegt Svelto, die extrapoleert dat er nog veel meer crashes moeten plaatsvinden omdat de crashrapportages optioneel zijn. "Bij 25.000 van die crashes detecteerden we een potentiële bit-flip", zegt Svelto. "Dat is ongeveer een op de twintig crashes die worden veroorzaakt door slecht of gebrekkig geheugen, een enorm cijfer!" Svelto noemt dat bovendien een conservatieve schatting vanwege de manier van meten, waardoor het werkelijke percentage volgens hem op tien procent ligt.

Dat betekent volgens Svelto dat zo'n tien procent van alle Firefox-crashes wordt veroorzaakt door hardwareproblemen. "Als ik daar crashes via middelenuitputting meeneem, zoals out-of-memory-crashes, dan gaat dat cijfer omhoog naar vijftien procent."

Svelto erkent dat de cijfers licht vertekend worden omdat gebruikers met slechte hardware ook vaker crashes zullen ervaren, maar toch 'verbleken oude schattingen rondom dit probleem' met die nieuwe gegevens.

Reacties (47)

[Sebazzz]

Mooi gerelateerd, in de categorie onmogelijke crashes: https://devblogs.microsof...hing/20050412-47/?p=35923

Het zou mij ook niet hier verbazen dat standaard overklokprofielen (XMP) hier ten grondslag liggen aan het probleem.

[downtime]

Dat lijkt me sterk. Het aantal mensen wat uberhaupt weet wat overklokken is, lijkt me niet zo groot.

[Robbierut4]

Onder de gehele populatie niet. Onder Firefox gebruikers zal dat aantal een stuk hoger liggen.

[Sebazzz]

Vergis je niet, zoals ook in het artikel genoemd wordt, dat sommige computers en moederborden standaard met een soort overklokconfiguratie ingeschakeld komen.

[Oon]

Tegenwoordig met XMP/DOCP e.d. is overclocken ingebakken in de marketing, als je het niet aanzet dan draait je hardware op lagere snelheid. Alle standaard OEM PC's hebben het dan ook gewoon aan staan, dus juist de mensen die niks van PC's weten en een kant en klare PC kopen raakt dit ook.

[Bruin Poeper]

Het aantal Firefox crashes lijkt me ook niet zo groot. Dus misschien is er toch een relatie met "wij Tweakers"?

Ik heb nog nooit Firefox crash meegemaakt (of ik ben het vergeten).

[itcouldbeanyone]

Ik ook niet , maar dat komt omdat als tweakers gebruik je natuurlijk standaard ECC,

[atthias]

1 of 2 keer op de desktop in stable release op windows 11

stuk of 6 keer op mobiel android 13 maar das de beta variant dus dat hoort er ook een beetje bij

[metalmania_666]

Ik geloof in al die jaren (FF gebruiker sinds 1.5) een keer of 5 waarvan 1 x zeker door foute hardware

[CriticalHit_NL]

Kan me anders ook wel herinneren dat Firefox ontiegelijk veel issues had in het verleden met hardware-acceleratie van de videokaarten, of dat hedendaags nog zo'n groot issue is betwijfel ik.

Nu is DDR5 wel in opkomst en die willen nog wel eens wat moeilijker doen i.v.m. de toegenomen complexiteit wat dus sneller voor instabiliteit kan zorgen met name op hogere snelheden en grotere capaciteiten.

Nu zal dat Intel debacle ook wel enig sinds meespelen, al hebben die vaak ironisch genoeg wel de betere interne geheugencontrollers, daar zit het hem weer in de CPU zelf.

Natuurlijk is bij menigeen hobbyist undervolten ook een hot-topic, maar dat kan soms ook net een tikkeltje te ver gaan met willekeurig crashende applicaties als gevolg.

Of je hebt games als WoW die bij bepaalde grafische instellingen gewoon doodleuk veel memory violations (advanced work submit) kan genereren ondanks dat het systeem verder hardware-matig prima is.

[R4gnax]

Kan me anders ook wel herinneren dat Firefox ontiegelijk veel issues had in het verleden met hardware-acceleratie van de videokaarten, of dat hedendaags nog zo'n groot issue is betwijfel ik.

Ze hebben inderdaad heel lang issues gehad met crashende video drivers waarbij de ingebouwde timeout detection & recovery (TDR) van Windows aansloeg om de driver gedeeltelijk te herstarten. Maar Firefox kon dat niet goed afhandelen waardoor op dat moment simpelweg de video output stopte.

Dat is in beperkte mate overigens nog steeds zo. Het afspelen van hardware accelerated video gaat in algemeenheid goed, maar als je scrollt terwijl de video afspeelt heb je een bepaalde willekeurige kans dat je een zelfde soort UI freeze krijgt als voorheen met de TDRs. Gebeurt met Nvidia, met AMD, met Intel graphics hardware- maakt eigenlijk niet uit welke vendor.

[Reactie gewijzigd door R4gnax op 6 maart 2026 19:09]

[oef!]

Dat is in mijn ervaring zeker mogelijk. Ik heb mijn ddr4 geheugen overgezet naar een nieuwer systeem dat instabiel bleek te zijn (crashende games). Na tests met memtest86 werd duidelijk dat het xmp profiel het issue was terwijl dat op het vorige moederbord geen issue was. Het geheugen op lagere snelheid laten draaien bleek de oplossing te zijn.

[84hannes]

Mooi gerelateerd, in de categorie onmogelijke crashes: https://devblogs.microsoft.com/oldnewthing/20050412-47/?p=35923

Goed verhaal

TL;DR

Omdat Microsoft de crashes niet konden verklaren vroegen ze de (volgende) 20 reporters contact op te nemen. De helft bleek bewust hun machine over te klokken. De andere helft bleek een overgeklokte machine te hebben gekocht. Je kunt hieruit voorzichtig concluderen dat overklokken niet goed is voor de stabiliteit van je machine.

Zowel Microsoft als Mozilla willen hier voorzichtig mee zeggen: als je denkt dat onze software buggy is (terwijl anderen dat niet zo ervaren) kijk dan eens naar je hardware. Maar ze durven het niet te hard te zeggen omdat iedereen dan denkt dat ze de schuld van hun eigen fouten aan anderen doorschuiven.

edit:
Quote met hyperlinks doet heel raar, handmatig aangepast

[Reactie gewijzigd door 84hannes op 6 maart 2026 20:33]

[whiner]

Firefox crashed erg vaak wanneer er te weinig swap is. Sinds ik mijn swap groter heb gemaakt heb ik geen crash meer gehad.

Maar dat is dus gewoon een memory beheer probleem. Moeten ze gewoon oplossen.

[PCG2020]

Het is wel typisch dat ik de afgelopen twee maanden in de Windows-versie van FF regelmatig de melding 'Ach! Uw tabblad is zojuist gecrasht!' kreeg. Volgens mij is dat begonnen met versie 146; daarvoor had ik er nooit last van. In versie 148 is het wel weer verminderd ten opzichte van 146 en 147, maar komt het alsnog zo nu en dan voor.

In de Linux-versie van FF heb ik er tot nu toe nooit last van gehad en toch gebruik ik daarin precies dezelfde extensies en zo.

[ramonfincken]

Ecc geheugen dan maar voor thuispc?

[uiltje]

Dat werkt misschien, maar ik heb bijvoorbeeld het sterke vermoeden dat een bios update mijn PC minder betrouwbaar had gemaakt. Ik gebruikte destijds ook firefox. Nadeel van PC's misschien; je configuratie is vaker buggy, zelfs bij A-merken. Nou is in mijn geval Asus dan de boosdoener en die hebben nooit goede SW of firmware support gehad. En als iemand zegt van niet, paste hier dan de laatste changelog van de software die je net gedownload hebt.

Maar even terug naar waar we waren: ja ECC kan inderdaad een gedeelte hiervan afdekken, en DDR5 zal hier al een gedeelte van meenemen vanwege de beperkte ingebouwde ECC.

[Reactie gewijzigd door uiltje op 6 maart 2026 18:07]

[JayPe]

Linus Torvalds zweert erbij.

[Dekar]

Kan, maar dan moet je wel een hele dure PC met EPYC, Threadripper of Xeon aanschaffen. Want Intel Core Ultra en AMD Ryzen ondersteunen het niet.

[dcm360]

AMD Ryzen ondersteunt wel degelijk ECC-geheugen. Bij de Pro-modellen is het gevalideerd, bij de overige modellen niet, maar in de praktijk werkt het.

[Dekar]

Alleen UDIMMs. Dat is praktisch geen ECC. Er bestaat ook geen AM5 moederbord met Registered ECC memory ondersteuning.

[dcm360]

UDIMM of RDIMM heeft weinig te maken met ECC, dat gaat alleen over of de geheugencontroller direct de geheugenchips aanspreekt of dat er nog een buffer tussen zit. AM5-moederborden met ondersteuning voor RDIMM's bestaan niet omdat de geheugencontroller op Ryzen CPU's geen RDIMM's kan aansturen, maar UDIMM's met ECC gaan dus prima.

[Dekar]

Het bufferen heeft alles te maken met ECC. Stel een bitflip gebeurt op de verbinding tussen CPU en RAM bijvoorbeeld door elektrische ruis of een defecte trace op het moederbord. Het RAM kan dat niet detecteren, want RAM voert zelf geen ECC-controle uit. De fout kan al in de data zitten voordat de ECC-controle plaatsvindt.

Daarom kan ECC UDIMM niet alle fouten detecteren. En zijn RDIMMs de enige versie van "echte" ECC.

[dcm360]

Zover ik weet zit de ECC-controle bij zowel UDIMM als RDIMM in de geheugencontroller (tegenwoordig dus op de CPU-package), en is er wat dat betreft geen verschil tussen de 2. Dit is althans hoe Wikipedia het uitlegt (en hoe het in mijn hoofd zit), maar ik ben altijd benieuwd naar een uitleg hoe het anders zit of kan.

[Dekar]

Natuurlijk wel. ECC staat voor Error Correcting Code.

Wikipedia: Registered memory

Wikipedia: ECC memory

[Reactie gewijzigd door Dekar op 6 maart 2026 18:13]

[RobinJ1995]

Fout. Single bit flips kunnen wel degelijk automatisch worden gecorrigeerd door ECC-geheugen.

[Mathijs Kok]

Dat lost het probleem niet echt op, er zit dan detectie op van een fout in het geheugen, maar niet de correctie. Gevolg is nog steeds een crash.

En dat op Tweakers. EEC geheugen kan fouten corrigeren, daarom gebruik je het.
Waarom niet eerst even uitzoeken voor je mening te geven?

[Ramon]

Sinds dat ik linux gebruik crashed Firefox inderdaad zo'n eens per maand vanwege out-of-memory issues. Op Windows had ik daar nooit last van; die haalde een maand uptime nooit.

Ik gebruik verder de extensie Dustman om oude tabs automatisch te sluiten; dat helpt redelijk tegen out-of-memory-errors.

[Step5]

hoeveel ram heeft die pc, en hoe groot is je swap?

[ApexAlpha]

Is een bitflip gerelateerd aan slechte hardware? Ik dacht dat dat gewoon kans was en dat je enkel met ECC memory dat kan voorkomen?

[sprankel]

Het zit complexer in elkaar,

-het risico kan groter of kleiner worden door de snelheid/timings, die bepalen immers hoe vaak een cel refreshed word maar terwijl dat gebeurd ben je niet bezig met performance
-onstabiele spanning helpt niet
-shielding speelt hier een rol

Je kan niet voorkomen dat je door brute pech net een ioniserende straal recht op een cel krijgt waardoor je een bit flip krijgt maar als je alle voorzorgen genomen hebt zoals bij een server gebeurd het zelden.

En dan kom je bij het volgende, als een server eens een bit flip heeft dan corrigeert die dat niet enkel, hij rapporteerd het ook.

In consumenten hardware gebeurd de bit flip en niemand weet het. Om dan ook nog eens net een bit flip te hebben in het geheugen van 1 specifiek software programma is wel heel specifiek.

Je kan er dus wel vanuit gaan dat de meeste crashes die zij zien vanwege bit flips dus niet het gevolg is van brute pech.

Overigens ooit 2 servers gehad die iets te vaak bit flips hadden, gerapporteerd met enterprise support dat er iets mis is met die productiebatch van ram. Vrij hard doorgeduwd maar ze bleven erbij dat het toeval was.

10 maanden later krijg ik een recall binnen voor een reeks servers vanwege productiefout in ram, ah, u hebt al dat ram al vervangen van 10 servers? Dat gesprek ging verder met veel euh euh

Als dat scenario zich bij servers met full enterprise support kan voordoen, dan zal het bij consumenten ook wel gebeuren en vermoedelijk veel vaker maar daar zal niemand erachter komen want je kan het niet eens aantonen, nergens kan je hard traceren dat er een bit flip was.

[ramonfincken]

Wij hebben afgelopen jaar een reep defecte ecc in een server gehad. Werd door het systeem netjes als kapot gemarkeerd. Komt zelden voor maar voor alles is een eerste keer.

Onder garantie uiteraard nieuw reepje ontvangen

[sprankel]

Dat heb ik al vaak voorgehad, hier ging het echt over 2 servers die kort na elkaar en herhaaldelijk bit flips hadden en 1 van de 2 was ook down gegaan door een multi bit flip. Dat die mission critical waren en backup van elkaar moet ik er mogelijks ook bijvertellen.

Het patroon kwam niet meer overeen met toeval, niet met een toevalige bitflip maar ook niet meer met toevallig is een slecht ramlatje gekregen. De fabrikant wilde wel het geheugen van die 2 servers vervangen maar bleef bij hoog en laag beweren dat het toeval was dat ik 2 keer slecht ram gekregen had in 2 servers, ik heb hun letterlijk gezegd dat ik met mijn toeval beter op de lotto zou spelen. Dan claimde ze dat ze een diepgaande analyse hadden gedaan in support tickets en geen enkele aanwijzing hadden dat die batch een probleem had. Ik heb dan op eigen bedrijfsbudget 10 servers hun geheugen gewisseld (met veel geblaas van management) omdat alles wees op een slechte productiebatch. Gelet de centrale beheertool die alle hardware via IPMI uitleest kon ik vrij eenvoudig een lijst trekken van hetzelfde type ram met ongeveer dezelfde productiedatum.

En dan kwam later de recall, we zijn alle klanten aan het opbellen en we hebben gezien dat er 10 van de serienummers van servers met recall bij jullie staan. Ja al dat ram moet vervangen worden mijnheer...

Edit: nu ik eraan terug denk, ik had nog een 3de server in een ander land staan die ook al 2 bit flips gemaakt had met dezelfde batch geheugen.

[Reactie gewijzigd door sprankel op 7 maart 2026 00:23]

[Mizgala28]

Ik denk dat ik in de afgelopen 15+ jaar zeker niet meer dan 20 echte crashes heb gehad met FF op Windows.

En van die 20 komt het grootste deel door hardwareversnelling.

Maar dit had makkelijk meer kunnen zijn als ik in een bepaalde periode paar jaar terug hardwareversnelling niet tijdelijk uit had geschakeld (dit heb ik al jaar of 4 weer aan, maar er was een periode waarbij ik vastlopers kreeg en andere issues vanwege hardwareversnelling in FF icm met (toen) een RTX 2070 Super).

Mijn partner had er toen ook last van op de (andere) desktop.

[Reactie gewijzigd door Mizgala28 op 6 maart 2026 18:28]

[latislos]

Wat is hun punt precies met dit nieuws?

Zouden Chromium browsers daar ook op crashen? of hebben ze het beter voor mekaar kwa regelen van geheugen en opvangen van die bitflip (Whatever it is ) ?

[sircampalot]

Het omvallen van bitjes: bitflip

Een klein probleem bij Firefox, een groot probleem in luchtvaart, maar daar komt het door externe factoren (dampkring dempt het effect)

[Reactie gewijzigd door sircampalot op 6 maart 2026 18:56]

[novw]

"het ligt aan die domme gebruiker die geen zin of geld heeft on het nieuwste van het nieuwst te kopen". En het ligt na-tuur-lijk niet aan Mozilla die veel te veel veel te snel veel te grof en veel te groot vernieuwd. Ik vind het leuk dat ze willen innoveren en boven het maaiveld willen uitsteken, maar ze vergeten wel rekening te houden met de 95% gebruikers die niet altijd alles nieuw willen hebben.

[Nutral]

Is dit niet een statistiek ding? Een deel van de crashreports zijn van bitflips, maar kapot geheugen zal veel vaker errors en dus een grotere kans hebben om bijv 10 crashes op 1 dag te veroorzaken dan 1. Zou dit meegerekend zijn in de vorm van het koppelen van meerdere crashreports van q pc? (Maar dit is dan weer een probleem qua privacy/anoniem)