作为一个数据点，这发生在我们的构建中:

02:13:00,465 WARN  - In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/ostream:133:
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:65: error: use of undeclared identifier '_'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^
02:13:00,465 WARN  - /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/locale:3180:67: error: use of undeclared identifier 'i'
02:13:00,465 WARN  - for (unsigned __i = 1; __i < __trailing_sign->size(); ++_^i, ++__b)
02:13:00,465 WARN  - ^

这看起来非常像在编译过程中偶然在源文件中非常重要的位置发生的位翻转。

我并不是说这是“宇宙射线”，但症状是相符的。

这是一个真正的问题，这就是为什么在服务器和嵌入式系统中使用ECC内存。以及为什么飞行系统与地面系统不同。

For example, note that Intel parts destined for "embedded" applications tend to add ECC to the spec sheet. A Bay Trail for a tablet lacks it, since it would make the memory a bit more expensive and possibly slower. And if a tablet crashes a program every once in a blue moon, the user does not care much. The software itself is far less reliable than the HW anyway. But for SKUs intended for use in industrial machinery and automotive, ECC is mandatory. Since here, we expect the SW to be far more reliable, and errors from random upsets would be a real issue.

通过IEC 61508和类似标准认证的系统通常都有启动测试，检查所有RAM是否正常(没有位卡在0或1)，以及运行时的错误处理，试图从ECC检测到的错误中恢复，通常还有内存清除任务，不断地遍历和读写内存，以确保发生的任何错误都能被注意到。

但是对于主流PC软件来说呢?没什么大不了的。对于长期存在的服务器?使用ECC和故障处理程序。如果一个不可纠正的错误杀死了内核，那就这样吧。或者你偏执地使用带有锁步执行的冗余系统，这样如果一个核心损坏，另一个核心可以在第一个核心重新启动时接管。

Memory errors are real, and ECC memory does help. Correctly implemented ECC memory will correct single bit errors and detect double bit errors (halting the system if such an error is detected.) You can see this from how regularly people complain about what seems to be a software problem that is resolved by running Memtest86 and discovering bad memory. Of course a transient failure caused by a cosmic ray is different to a consistently failing piece of memory, but it is relevant to the broader question of how much you should trust your memory to operate correctly.

基于20 MB常驻大小的分析可能适用于普通应用程序，但大型系统通常有多个具有较大主存的服务器。

有趣的链接:http://cr.yp.to/hardware/ecc.html

不幸的是，海盗链接在页面似乎死了，所以查看海盗链接在这里代替。

“宇宙射线事件”在这里的许多答案中被认为是均匀分布的，这可能并不总是正确的(即超新星)。虽然“宇宙射线”的定义(至少根据维基百科)来自外太空，但我认为将局部太阳风暴(又名日冕物质抛射)也包括在同一保护伞下是公平的。我相信这可能会导致几个比特在短时间内翻转，可能足以破坏甚至启用ecc的内存。

众所周知，太阳风暴会对电力系统造成相当大的破坏(如1989年3月的魁北克停电)。计算机系统很可能也会受到影响。

Some 10 years ago I was sitting right next to another guy, we were sitting with each our laptops, it was in a period with quite "stormy" solar weather (sitting in the arctic, we could observe this indirectly - lots of aurora borealis to be seen). Suddenly - in the very same instant - both our laptops crashed. He was running OS X, and I was running Linux. Neither of us are used to the laptops crashing - it's a quite rare thing on Linux and OS X. Common software bugs can more or less be ruled out since we were running on different OS'es (and it didn't happen during a leap second). I've come to attribute that event to "cosmic radiation".

后来，“宇宙辐射”成了我工作场所的一个内部笑话。每当我们的服务器发生了什么事情，我们找不到任何解释，我们开玩笑地把错误归咎于“宇宙辐射”。: -)

我经历过这种情况——宇宙射线翻转一点并不罕见，但一个人观察到这种情况的可能性很小。

2004年，我正在为一个安装程序开发一个压缩工具。我的测试数据是一些Adobe安装文件，压缩了大约500 MB或更多。

在冗长的压缩运行和解压运行以测试完整性之后，FC /B显示一个字节不同。

在这一个字节内，MSB翻转了。 我也急了，担心我有一个疯狂的bug，它只会在非常特定的条件下出现——我甚至不知道从哪里开始寻找。

但有声音让我再做一次测试。我运行它，它通过了。我设置了一个脚本，在一夜之间运行测试5次。到了早上，5个都已经过去了。

所以这绝对是宇宙射线位翻转。

您可能还想看看容错硬件。

例如，Stratus Technology构建了名为ftServer的Wintel服务器，它有2或3个锁步“主板”，比较计算结果。(有时在太空飞行器中也会这样做)。

Stratus服务器从定制芯片组发展到背板上的同步。

一个非常类似的(但是是软件)系统是基于Hypervisor的VMWare Fault Tolerance lockstep。