411–420 of 495 posts
Earlier quoted context omitted.
For safety critical systems, one strategy is to store at least two copies of important data and compare them regularly. If they don't match, you either try to recover somehow or go into a safe state, depending on the context.
At least three copies, so you can recover based on consensus.
Earlier quoted context omitted.
That would tell you if there's a bitflip in your test, but not if there's a bitflip in normal program code causing a crash, no? IIUC GP's questions was how do they actually tell after a crash that that crash was caused by a bitflip.
The example I gave in there is of adding sentinel values in your data, so you can check the constants in your data structures later and go "oh, this is overwritten with garbage" versus "oh, this is one or two bits off". I would imagine plumbing things like that through most common structures is what was done there, though I haven't done the archaeology to find out, because Firefox is an enormous codebase to try and f…
I’ve also found that compiling large packages in GCC or similar tends to surface problems with the system’s RAM. Which probably means most typical software is resilient to a bit-flip; makes you wonder how many typos in actual documents might have been caused by bad R@M.
Earlier quoted context omitted.
Firefox has a long history of denying problems, blaming the user, and fixing the issue years later. It used to be memory usage, now it's crashing.
Did you actually read the posts that started this topic, or are you being an ass for no reason? Hint: No-one is claiming memory is to blame for 100% of the Firefox crashes. No-one is claiming it's 99% either.
Sorry, but I experienced first hand Firefox's memory leaks not being taken seriously. This "bitflips" news is just released, but I fully expect anybody complaining about Firefox crashes to be met with low effort "It's your RAM," responses for the next few years now.
Earlier quoted context omitted.
At least three copies, so you can recover based on consensus.
“never go to sea with two chronometers, take one or three”
The next logical step would be to somehow inform users so they could take action to replace the bad memory. I realize this is a challenge given the anonymized nature of the crash data, but I might be willing to trade some anonymity in exchange for stability.
That's different from what you're suggesting, because you're right that the crash reports are analyzed with heuristics to guess at memory corruption. Aside from the privacy implications, though, I think that would have too many false alarms. A single bit flip is usually going to be an out of bounds write, not bad RAM.
Earlier quoted context omitted.
Compilers and test suits do scale (at least for C/C++ and Rust, which is what I work with). But I think the parent comment referred to consumer applications: games, word processing, light browsing, ... (Though games these days scale better than they used to, but only up to a to a point.) I find that most tools I write for my own use can be made to scale with cores, or run so fast that the overhead of starting threads…
But those tools aren't really compute bound anyway - you're not buying a workstation to do them, you're getting a consumer laptop or a tablet.
Earlier quoted context omitted.
Very few applications scale with cores. For the vast majority of people single core performance is all they care about, it's also cheaper. They don't need or want workstation gear.
> Very few applications scale with cores You mean like compilers and test suites ? Very few professional workloads don't parallelize well these days.
[flagged]
People experience "blue screens" and kernel panics and such pretty often.