Technology

Unprovoked bitfllips then

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.

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.

No, the exact % depends on how stable everything else is.

Like a trivial example, if you have 3 programs, one that sets a pointer to a random address and tries to dereference it, one that does this but only if the last two digits of a timer it checks are "69", and one that never sets a pointer to an invalid address, based on the programs themselves, the first one will crash almost all the time, the second one will crash about 1% of the time, and the third one won't crash at all.

If you had a mechanism to perfectly detect bit flips (honestly, that part has me the most curious about the OP), and you ran each program until you had detected 5 bit flip crashes (let's say they happen 1 out of each 10k runs), then the first program will have something like a 0.01% chance of any given crash being due to bit flip, about 1% for the 2nd one, and 100% for the 3rd one (assuming no other issues like OS stability causing other crashes).

Going with those numbers I made up, every 10k "runs", you'd see 1 crash from bit flips and 9 crashes from other reasons. Or for every crash report they receive, 1 of 10 are bit flips, and 9 of 10 are "other". Well, more accurately, 1 of 20 for bit flip and 19 of 20 for other, due to the assumption that the detector only detects half of them, because they actually only measured 5%.

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.

Maybe it was too vanilla to crash. 🍨

Ouch, my condolences to your wallet

Time to make a compromise by buying the cheapest €130 8GB stick.

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.)

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

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.