一行代码引发的“血案”：价值5亿欧元的火箭，发射40秒后凌空爆炸
1996 年 6 月 4 日星期二，欧洲航天局计划首次发射新的阿丽亚娜（Ariane）5 型火箭。作为经过十年设计、测试和数十亿欧元投入的科技结晶，这枚运载火箭牵动着每位欧洲航天人的心。
准备发射的阿丽亚娜 5 型火箭
这枚火箭的设计目标非常简单，同时也承载着巨大风险。它需要将昂贵的大载荷送入太空，帮助欧洲完成一系列科学实验与商业项目。
火箭上没有搭载宇航员，最尊贵的“乘客”是 Cluster 航天器。这台设备由四颗昂贵的科学卫星组成，每颗重 2600 磅。
然而，就在起飞后短短 40 秒，阿丽亚娜 501 号就在发射区上空炸裂成无数金属残片和燃烧的碎块。对于欧洲航天局来说，这不仅是一次沉重的打击，更是一场令人震惊的灾难。
阿丽亚娜 501 号升空几秒后即发生爆炸
事故原因其实非常简单 — 一个本可以轻松避免的编码 bug。这个 bug 来自一段死代码（即不产生实际作用的代码），属于近十年前阿丽亚娜 4 型火箭的遗留产物。
阿丽亚娜 501 号火箭在脱离发射台后，会按照预定路径平稳加速并飞向太空。在内部，制导系统不断跟踪火箭轨迹并将数据发送至主机载计算机。为了完成数据传输，制导系统需要将速度读数从 64 位浮点数转换为 16 位带符号整数。
大家可以想想，这个转换过程究竟是怎么回事。使用 16 位无符号整数，我们可以存储 0 到 65535 之间的任意值。而如果把首位用来存放符号（正 / 负），那么 16 位有符号整数就能涵盖从 -32768 到 +32768 的任意值（实际可用数位只有 15 位）。任何超出这个范围的值都无法正常使用。
另一方面，浮点数的存储规则略有不同，强调的是在相同的位数中覆盖更大范围的数字。例如，即使是 16 位（双精度）浮点数，也能存储从 -1.8e+308 到 -2.2e-308 之间的大量值。可见，要把其中的某个值转换成 16 位有符号整数，则很可能会超出后者的支持范围。那如果是 64 位浮点数呢？结果只会更糟。
一旦这种不可避免的事态成真，会有怎样的后果？在使用 16 位有符号整数时，从浮点数到整数的转换会引发我们熟知的整数溢出。现在只剩最后一个问题了：整数溢出，对于火箭发射意味着什么？
制导系统会读取火箭的水平速度数据（64 位浮点数），并尝试将其转换为 16 位整数以发送至主计算机。但转换未能成功。
很明显，因为读数大于 16 位整数所能表示的最大值，所以转换失败。一般来讲，设计良好的系统会内置一个程序来处理溢出错误，并向主计算机发送一条合理的消息。但阿丽亚娜并不是这样……
制导系统会持续发送错误消息，于是主计算机不但接收不到正确的水平速度值，制导系统那边还被立即关闭了。
但有些朋友可能会问，应该有补救措施吧？火箭制导系统难道就没有后备吗？当然有，但后备系统的代码跟主系统完全相同，所以它也在尝试执行同样的转换、得到相同的错误，于是短短 72 毫秒后也崩溃了。
因为没有异常处理代码，主计算机将发来的数据解释成了真正的导航数据，认定火箭已经严重偏离航线。为了消解这个根本就不存在的威胁，助推器点燃了全喷嘴偏转，巨大的空气动力压力立即开始撕裂火箭本体。
一名科学家站在多次执行阿丽亚娜发射任务的 HM-7B 火箭发动机旁
计算机意识到情况到了最危急的关头，于是决定触发自毁机制，把这枚当时造价约 5 亿欧元的火箭当成大炮仗给放了。
也就是说，这场灾难性且耗资巨大的飞行事故，其根源就是一行代码尝试将 64 位浮点数转换成有符号整数，整数溢出结果被直接传递给主计算机，最终被主计算机解释为真实数据。
同样的软件设计之前已经成功服务过多次发射，但那时候是在阿丽亚娜 4 型火箭上。4 型火箭体量较小，所以性能参数也远低于 5 型；新的阿丽亚娜 5 型火箭在显著升级之后，飞行速度超出了系统工程师当初编写代码时的取值区间。
可预定飞行速度可能导致溢出错误的事，应该不会逃过工程师的眼睛才对。
确实如此，前文提到，这个 bug 来自一段死代码。因为这部分只是发射台对齐过程中的一部分，在起飞后就不再需要了。但当时一个小小的故障将发射延迟了几秒钟，为了避免重置整个系统，软件工程师决定额外把整个代码序列运行一遍……
于是在升空 40 秒后，5 亿欧元和无数人的心血瞬间化为乌有。
原文链接：
https://jam.dev/blog/famous-bugs-rocket-launch
往期推荐：
技术琐话
以分布式设计、架构、体系思想为基础，兼论研发相关的点点滴滴，不限于代码、质量体系和研发管理。