最可怕的 Bug，是你写了 100% 正确的代码，机器却硬生生给你“编”错了。 这就是硅谷著名的 “Core 59” 悬…

最可怕的 Bug，是你写了 100% 正确的代码，机器却硬生生给你“编”错了。

这就是硅谷著名的 “Core 59” 悬案。 当时 Facebook 的 Spark 数据库在跑任务时，经常莫名其妙地丢失随机文件。 没有报错，没有崩溃，数据就是凭空消失了。 这种“无声的错误”（Silent Error），能逼疯最冷静的程序员。

Facebook 派出了顶尖的工程团队，开始了一场史诗级的 Debug 过程。 他们把范围一步步缩小，最后锁定了 Scala 语言里的 math.pow() 求幂函数。 而且，他们发现了一个规律： 这个 Bug，只要分配到 CPU 的 Core 59（第 59 号核心）上，就会 100% 重现！

为什么会这样？ 我们现代软件栈的信任链，其实长得可怕。 你写的高级代码，要先变成 Java 字节码，再通过 Java 虚拟机（JVM）的 JIT 即时编译器，在运行时翻译成 CPU 看得懂的汇编指令。 问题，就出在翻译官身上。

为了抓出这个内鬼，排查团队把 JIT 编译出来的机器码导了出来。 整整 43 万行汇编代码。 他们硬生生把这 43 万行精简到了 400 行。 最后，通过 GDB 调试寄存器，终于抓到了元凶： 在把公式编译成机器码时，编译器产生了一条错误的机器指令。

代码是对的，公式是对的，但编译器给出的最终指令是错的。 这就是为什么这桩案子让技术圈至今提起都心有余悸。 我们每天写着代码，默认底层的编译器、操作系统、芯片都是绝对诚实和无懈可击的。 但当你在几十万行自动生成的汇编代码深处看到那条“走火入魔”的指令时，你才会意识到： 现代科技的摩天大楼，其实是一座建立在概率和层层黑盒之上的惊险杰作。