一行代码引发的血案价值5亿欧元的火箭

年6月4日星期二，欧洲航天局计划首次发射新的阿丽亚娜（Ariane）5型火箭。作为经过十年设计、测试和数十亿欧元投入的科技结晶，这枚运载火箭牵动着每位欧洲航天人的心。

准备发射的阿丽亚娜5型火箭

这枚火箭的设计目标非常简单，同时也承载着巨大风险。它需要将昂贵的大载荷送入太空，帮助欧洲完成一系列科学实验与商业项目。

火箭上没有搭载宇航员，最尊贵的“乘客”是Cluster航天器。这台设备由四颗昂贵的科学卫星组成，每颗重磅。

然而，就在起飞后短短40秒，阿丽亚娜号就在发射区上空炸裂成无数金属残片和燃烧的碎块。对于欧洲航天局来说，这不仅是一次沉重的打击，更是一场令人震惊的灾难。

阿丽亚娜号升空几秒后即发生爆炸

事故原因其实非常简单—一个本可以轻松避免的编码bug。这个bug来自一段死代码（即不产生实际作用的代码），属于近十年前阿丽亚娜4型火箭的遗留产物。

阿丽亚娜号火箭在脱离发射台后，会按照预定路径平稳加速并飞向太空。在内部，制导系统不断跟踪火箭轨迹并将数据发送至主机载计算机。为了完成数据传输，制导系统需要将速度读数从64位浮点数转换为16位带符号整数。

大家可以想想，这个转换过程究竟是怎么回事。使用16位无符号整数，我们可以存储0到之间的任意值。而如果把首位用来存放符号（正/负），那么16位有符号整数就能涵盖从-到+的任意值（实际可用数位只有15位）。任何超出这个范围的值都无法正常使用。

另一方面，浮点数的存储规则略有不同，强调的是在相同的位数中覆盖更大范围的数字。例如，即使是16位（双精度）浮点数，也能存储从-1.8e+到-2.2e-之间的大量值。可见，要把其中的某个值转换成16位有符号整数，则很可能会超出后者的支持范围。那如果是64位浮点数呢？结果只会更糟。

一旦这种不可避免的事态成真，会有怎样的后果？在使用16位有符号整数时，从浮点数到整数的转换会引发我们熟知的整数溢出。现在只剩最后一个问题了：整数溢出，对于火箭发射意味着什么？

制导系统会读取火箭的水平速度数据（64位浮点数），并尝试将其转换为16位整数以发送至主计算机。但转换未能成功。

很明显，因为读数大于16位整数所能表示的最大值，所以转换失败。一般来讲，设计良好的系统会内置一个程序来处理溢出错误，并向主计算机发送一条合理的消息。但阿丽亚娜并不是这样……

制导系统会持续发送错误消息，于是主计算机不但接收不到正确的水平速度值，制导系统那边还被立即关闭了。

但有些朋友可能会问，应该有补救措施吧？火箭制导系统难道就没有后备吗？当然有，但后备系统的代码跟主系统完全相同，所以它也在尝试执行同样的转换、得到相同的错误，于是短短72毫秒后也崩溃了。

因为没有异常处理代码，主计算机将发来的数据解释成了真正的导航数据，认定火箭已经严重偏离航线。为了消解这个根本就不存在的威胁，助推器点燃了全喷嘴偏转，巨大的空气动力压力立即开始撕裂火箭本体。

一名科学家站在多次执行阿丽亚娜发射任务的HM-7B火箭发动机旁

计算机意识到情况到了最危急的关头，于是决定触发自毁机制，把这枚当时造价约5亿欧元的火箭当成大炮仗给放了。

也就是说，这场灾难性且耗资巨大的飞行事故，其根源就是一行代码尝试将64位浮点数转换成有符号整数，整数溢出结果被直接传递给主计算机，最终被主计算机解释为真实数据。

同样的软件设计之前已经成功服务过多次发射，但那时候是在阿丽亚娜4型火箭上。4型火箭体量较小，所以性能参数也远低于5型；新的阿丽亚娜5型火箭在显著升级之后，飞行速度超出了系统工程师当初编写代码时的取值区间。

可预定飞行速度可能导致溢出错误的事，应该不会逃过工程师的眼睛才对。

确实如此，前文提到，这个bug来自一段死代码。因为这部分只是发射台对齐过程中的一部分，在起飞后就不再需要了。但当时一个小小的故障将发射延迟了几秒钟，为了避免重置整个系统，软件工程师决定额外把整个代码序列运行一遍……

于是在升空40秒后，5亿欧元和无数人的心血瞬间化为乌有。

原文链接：