Firefox kept crashing on me a few days ago. Decided to run MemTest86 and sure enough. Bad RAM.
this post was submitted on 06 Mar 2026
347 points (97.5% liked)
Technology
82460 readers
3708 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
Ouch, my condolences to your wallet
Time to make a compromise by buying the cheapest €130 8GB stick.
Luckily for me, I was already running 64GB so now I’m down to 32GB. I can try to wait it out. -_- I don’t really need that much anyway, but I’m glad I had it when it was cheap
Technically every that happens on a computer is a bit flip 😏
Unprovoked bitfllips then
I really don't remember the last time Firefox crashed on me and I've been using it for many years
load more comments
(5 replies)
This is how dev humblebrag sounds like.
Our app is so stable only random hardware events like bitflips can crash it.
LOL, nah, Firefox isn't that stable. If 10% of crashes were caused by bad RAM, it means 90% were still caused by something else.
(My install regularly gets a memory leak that eventually makes my system unusable, BTW. I don't think it's necessarily the fault of Firefox itself -- more likely Javascript running in tabs, maybe interacting with an extension or something, and some of the blame goes to the kernel's poor handling of low memory conditions -- but it's definitely not "dev humblebrag stable" for me.)
10% of all crashes is definitively a brag. Crashes due to faulty hardware/bitflips is rare rare, generally I would expect that percentage to be less than 1% in any complex app
And ECC memory still isn't standard in PC computers
God I wish
I flip my bits looking at porn using FireFox and that shit almost never crashes 🤷♂️
Maybe it was too vanilla to crash. 🍨
I used to be a part of an anticheat dev team and we discovered that this was a common problem back in the Windows XP era.
We added a routine to check the memory addresses used after a crash and notified the user if we suspected hardware failure.
At the time we suspected unstable overclocks because the metrics showed us the computers affected were typically overclocked as well.
*interest in parity-checking server RAM intensifies*
When I upgrade my home server I would like a low-power system with ECC RAM. I hope it will be financially viable in the future.
The problem is that ECC is one of the things used to permit price discrimination between server (less price sensitive) and PC (more price sensitive) users. Like, there's a significant price difference, more than cost-of-manufacture would warrant. There are only a few companies that make motherboard chipsets, like Intel, and they have enough price control over the industry that they can do that. You're going to be paying a fair bit more to get into the "server" ecosystem, as a result of that.
Also...I'm not sure that ECC is the right fix. I kind of wonder whether the fact is actually that the memory is broken, or that people are manually overclocking and running memory that would be stable at a lower rate at too high of a rate, which will cause that. Or whether BIOSes, which can automatically detect a viable rate by testing memory, are simply being too aggressive in choosing high memory bandwidth rates.
EDIT: If it is actually broken memory and only a region of memory is affected, both Linux and Windows have the ability to map around detected bad regions in memory, if you have the bootloader tell the kernel about them and enough of your memory is working to actually get your kernel up and running during initial boot. So it is viable to run systems that actually do have broken memory, if one can localize the problem.
https://www.gnu.org/software/grub/manual/grub/html_node/badram.html
Something like MemTest86 is a more-effective way to do this, because it can touch all the memory. However, you can even do runtime detection of this with Linux up and running using something like memtester, so hypothetically someone could write a software package to detect this, update GRUB to be aware of the bad memory location, and after a reboot, just work correctly (well, with a small amount less memory available to the system...)
load more comments
(3 replies)
load more comments
(4 replies)
The 90% are caused by Fhqwhgads.
Fhqwhgads pushes every bit to the limit.
Well, that's unnerving.
How so?
Didn't it just highlight how stable the software is?
I assume bitflipping crashes most softwares. If your software is so stable that hardware errors that effect everyone equally(which may be my erroneous assumption I'll admit) then it is staying that if Firefox is crashing on you, it might be time to run some diagnosis on your hardware.
A litmus test as a browser
Fair question. I find it unnerving, because there's very little a software developer can meaningfully do if they cannot rely on the integrity of the hardware upon which their software is running, at least not without significant costs, and ultimately if the problem is bad enough even those would fail. This finding seems to indicate that a lot of hardware is much, much less reliable than I would have thought. I've written software for almost thirty years and across numerous platforms at this point, and the thought that I cannot assume a value stored in RAM to reliably retain it's value fills me with the kind of dread I wouldn't be able to explain to someone uninitiated without a major digression. Almost everything you do on any computing device - whether a server or a smart phone relies on the assumption of that kind of trust. And this seems to show that assumption is not merely flawed, but badly flawed.
Suppose you were a car mechanic confronted with a survey that 10 percent of cars were leaking breaking fluid - or fuel. That might illustrate how this makes me feel.
load more comments
(2 replies)
What makes Firefox more susceptible to bitflips than any other software? Wouldn't that mean that 10% of all software crashes are caused by bitflips and it just depends what software you are running when that happens.
I don't think they're arguing that Firefox is more susceptible to bit flips. They're trying to say that their software is "solid" enough that a significant number of the reported crashes are due to faulty hardware, which is essentially out of their control.
If other software used the same methodology, you could probably use the numbers to statistically compare how "solid" the code base is between the two programs. For example, if the other software found that 20% of their crashes were caused by bit flips, you could reasonably assume that the other software is built better because a smaller portion of their crashes is within their control.
load more comments
(1 replies)
This checks out with Linus Torvalds saying most OS crashes across linux AND windows are caused by hardware issues, and also why he uses ECC RAM.
load more comments
(2 replies)
Programs that use more memory could be slightly more susceptible to this sort of thing because if a bit gets randomly flipped somewhere in a computer's memory, the bit flip more likely to happen in an application that has a larger ram footprint as opposed to an application with a small ram footprint.
I'm still surprised the percentage is this high.
load more comments
(1 replies)
load more comments
(2 replies)
Wouldn’t that mean ten percent of all crashes in all apps would be caused by bit flips? What makes Firefox special?
You can't effect the number of bit flips your users hardware has, but you can affect how often buggy code corrupts their memory or otherwise crashes your program.
Let's say any app will crash about once a year on my machine due to a bit flip. If the app is crap and crashes hundreds of times for other reasons, the bit flip is irrelevant. If the app is robust enough that the bit flip accounts for 10 % of the crashes, that basically means the app is pretty much never crashing due to poor code.
That's the way people should be looking at it. It basically means hard crashes are extremely rare in the firefox ecosystem.
To be fair, I can't remember the last time a browser crashed on me in general.
load more comments
(1 replies)
Anecdotal evidence, but I had both a 13th gen and 14th gen Intel CPU with the bug that caused them to over time, destroy themselves internally.
The most-user-visible way this initially came up, before the CPUs had degraded too far, was Firefox starting to crash, to the point that I initially used Firefox hitting some websites as my test case when I started the (painful) task of trying to diagnose the problem. I suspect that it's because Firefox touches a lot of memory, and is (normally) fairly stable
a lot of people might not be too surprised if some random game crashes.
load more comments
(1 replies)
load more comments
(8 replies)
view more: next ›