产品终局：每个变化都充满重大风险，第二集

<p>一位同事讲述了这个在Word 97发布周期最后阶段出现的bug的故事。</p> <p>测试团队在一个较为常见的代码路径中发现了一个阻碍发布的bug。坏消息是这个bug是偶发的。好消息是测试团队编写了一个脚本，能在实验室中以相当好的可靠性触发崩溃。坏消息是当你使用调试器时，bug就消失了。</p> <p>开发团队非常焦虑，因为这种仅在实验室中偶发出现的bug<a title="百万分之一的概率就在下周二" href="https://learn.microsoft.com/en-us/archive/blogs/larryosterman/one-in-a-million-is-next-tuesday">在实际使用中会经常出现</a>。但是，如何调试一个抵抗调试的问题呢？</p> <p>有人建议使用在线仿真器（ICE），它基本上是一台运行CPU仿真器的<a title="在线仿真：用于软件调试的强大硬件工具" href="https://www.rcollins.org/ddj/Jul97/">独立计算机</a>。ICE有一根电缆插入目标机器的CPU插座，这就是ICE能够仿真CPU操作的机制：通过物理复制真实CPU会产生的电CPU被仿真，你可以使用ICE在CPU内部发生的事情上设置断点，比如“当CPU禁用中断时，将值42写入此内存位置时中断”。（尽管在这种情况下，它只是用于从外部系统设置断点和检查内存。）对于大多数软件开发者来说，在线仿真器只存在于神话中，获得并使用它的可能性让五岁的小男孩得知他可能乘坐消防车时一样兴奋。</p> <p>领导调查的开发者们欣喜若狂，当他们发现大多数崩溃系统来自同一制造商，并且都是在特定日期之前制造的。此时，不久之后就发现了一个CPU勘误，与受影响系统的制造日期相符。</p> <p>现在，他们使用的编译器已经发布了更新以避免有问题的代码序列，但团队在更新可用之前已经锁定了他们的工具集，并且在<a title="微话语：托管" href="https://devblogs.microsoft.com/oldnewthing/20260217-00/?p=112067">托管期间</a>升级编译器不是个好主意，因为谁知道切换到新编译器会引入哪些新bug。²</p> <p>团队编写了一个工具来扫描他们的二进制文件，查找任何可能触发CPU勘误的代码序列。²他们发现了大约150个有问题的代码序列实例，但CPU错误的一个要求是序列跨越页面边界，而这150个实例中只有一个跨越了页面边界。</p> <p>而且他们的测试人员找到了它。</p> <p>为了避免修复引入任何新问题，团队选择对二进制文件进行二进制补丁，在有问题的代码序列中插入一个<code>nop</code>。这足以避免CPU勘误，而不会让其他代码面临回归风险。</p> <p><b>额外阅读</b>：<a title="产品终局：每个变化都充满重大风险" href="https://devblogs.microsoft.com/oldnewthing/20091104-01/?p=16143">相关故事</a>。</p> <p>¹ 补充阅读：<a title="微话语详解：托管不只是发布候选版本的另一个名字吗？" href="https://devblogs.microsoft.com/oldnewthing/20260623-00/?p=112462">托管 vs. 发布候选版本</a>。</p> <p>² 编译器可能有bug被产品源代码触发的风险很小，但更大的风险是产品源代码中存在预存在的bug，这些bug会被新编译器暴露。例如，未初始化的变量bug可能被旧编译器的内存布局选择所掩盖，因为之前的内存使用是一个从未为null的指针，但新编译器对局部变量的布局不同，现在之前的内存使用是一个有时为零的整数。</p> <p><a title="我的，你有什么奇怪的NOP！" href="https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11773">听起来熟悉吗</a>？</p> <p>帖子<a href="https://devblogs.microsoft.com/oldnewthing/20260826-00/?p=112649">产品终局：每个变化都充满重大风险，第二集</a>首次出现在<a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a>。</p>