翻译《有关编程、重构及其他的终极问题？》——36.如果你在电脑上发现一些奇怪的事情，看看内存吧

翻译《有关编程、重构及其他的终极问题？》——36.如果你在电脑上发现一些奇怪的事情，看看内存吧

标签（空格分隔）：翻译 技术 C/C++
作者：Andrey Karpov
翻译者：顾笑群 - Rafael Gu
最后更新：2018年08月15日

---

36.如果你在电脑上发现一些奇怪的事情，看看内存吧

我觉得之前写的那么多错误的套路（译者注：指之前那些章节）已经把你弄晕了，所以这次，我们休息一下，就看看代码吧。

我们常遇到一种典型的情况就是，程序不能正常工作，但你却丝毫没有头绪为何会如此。遇到这种情况，我建议先不要马上去责备某些人，而是聚焦于你的代码上。导致这种情况的原因，99.99%的可能性是你研发团队某个成员的bug导致的，而且这个bug一般来说是非常愚蠢和低级的。所以去查看下代码，花些时间找出这个bug。

（译者注：后面讲了如果不是上面的问题的话，剩余0.01%的可能性的情况）

事实上，如果bug是时而出现的，无法定位，那么也许你遇到了海森堡bug。

另外，虽然把错误归咎于编译器是一个更糟糕的注意，但编译器的确可能犯错，虽然几率很低。比如，你会尴尬的发现，你错误的使用了sizeof()（译者注：sizeof是编译阶段处理的符号）。关于这点，我曾写过一篇博文：备受指责的编译器

让我们回到要讨论的话题，也就是除了以上还有其他异常原因导致错误。有时候bug和代码一点关系也没有，虽然这很少发生，但我们必须意识到这有可能存在，这会让我们保持全面的理智。

我会用一个实际的例子来给大家演示我曾经遇到的问题，而且幸运的时，当时我的截图还在。

那时，我正在写一个简单的测试项目用来演示Viva64分析器（PVS-Sutdio的处理器）的能力，但这个项目不能正常工作。

在经过长期和乏味的调查后，我发现时一个内存插槽导致了这个问题，确切的说是一个bit导致的。你可以看下面我在Debug模式的图片，我在内存中直接写入了3作为那个地址的值。

在这个内存值被修改后，debugger读取这个修改后的值显示在windows上，但结果显示的却是2：看吧，时0x02（译者注：不是作者前面手动修改的3）。虽然我已经把那个内存值修改为3，但低位的bit位始终是0。

我用一个内存测试工具确认了以上问题。奇怪的是，那台电脑工作的很正常，没有任务问题。在使用了另外一个内存插槽后，我的那个测试项目也正常工作了。

我非常幸运，因为我只是要面对的一个测试项目。但这还是让我花费了很多时间去理解到底发生了什么事情：我使用了超过两个小时检查了程序的编译和组装，试图发现导致这个奇怪行为的原因——是的，我开始把原因归咎于编译器。

我不能想象如果这是一个真实的项目，那还会花费多少时间。感谢上帝我那时不需要调试其他更多的东西。

建议

只在代码中找错误，不要尝试转移责任。

然而，如果这个bug只发生在你的电脑上，而且超过一周，那就有可能不是你代码的问题了。

继续查找bug吧，但是回家前，运行一晚RAM测试程序吧，也许这个小工作可以拯救你。