{"id":"16102690","account":"mubei","brand":"@mubei","title":"最可怕的 Bug，是你写了 100% 正确的代码，机器却硬生生给你“编”错了。 这就是硅谷著名的 “Core 59” 悬…","summary":"最可怕的 Bug，是你写了 100% 正确的代码，机器却硬生生给你“编”错了。 这就是硅谷著名的 “Core 59” 悬案。 当时 Facebook 的 Spark 数据库在跑任务时，经常莫名其妙地丢失随机文件。 没有报错，没有崩溃，数据就是凭空消失了。 这种“无声的错误”（Si…","body":"最可怕的 Bug，是你写了 100% 正确的代码，机器却硬生生给你“编”错了。\n\n这就是硅谷著名的 “Core 59” 悬案。\n当时 Facebook 的 Spark 数据库在跑任务时，经常莫名其妙地丢失随机文件。\n没有报错，没有崩溃，数据就是凭空消失了。\n这种“无声的错误”（Silent Error），能逼疯最冷静的程序员。\n\nFacebook 派出了顶尖的工程团队，开始了一场史诗级的 Debug 过程。\n他们把范围一步步缩小，最后锁定了 Scala 语言里的 math.pow() 求幂函数。\n而且，他们发现了一个规律：\n这个 Bug，只要分配到 CPU 的 Core 59（第 59 号核心）上，就会 100% 重现！\n\n为什么会这样？\n我们现代软件栈的信任链，其实长得可怕。\n你写的高级代码，要先变成 Java 字节码，再通过 Java 虚拟机（JVM）的 JIT 即时编译器，在运行时翻译成 CPU 看得懂的汇编指令。\n问题，就出在翻译官身上。\n\n为了抓出这个内鬼，排查团队把 JIT 编译出来的机器码导了出来。\n整整 43 万行汇编代码。\n他们硬生生把这 43 万行精简到了 400 行。\n最后，通过 GDB 调试寄存器，终于抓到了元凶：\n在把公式编译成机器码时，编译器产生了一条错误的机器指令。\n\n代码是对的，公式是对的，但编译器给出的最终指令是错的。\n这就是为什么这桩案子让技术圈至今提起都心有余悸。\n我们每天写着代码，默认底层的编译器、操作系统、芯片都是绝对诚实和无懈可击的。\n但当你在几十万行自动生成的汇编代码深处看到那条“走火入魔”的指令时，你才会意识到：\n现代科技的摩天大楼，其实是一座建立在概率和层层黑盒之上的惊险杰作。","category":"其它","score":null,"percentile":null,"reason_tags":[],"translated_x_url":"https://x.com/i/status/2072250268683473135","translated_status_id":"2072250268683473135","published_at":"2026-07-01 08:58:22","created_at":"2026-07-01T10:52:28+02:00"}