本节书摘来自华章出版社《Effective Debugging：软件和系统调试的66个有效方法》一书中的第1章，第1.5节，作［希］迪欧米迪斯·斯宾奈里斯（Diomidis Spinellis），更多章节内容可以访问云栖社区“华章计算机”公众号查看

第5条：在能够正常运作的系统与发生故障的系统之间寻找差别

我们通常都能够同时访问这样两个系统，其中一个是发生故障的系统，另一个是与之相似但却可以正常运行的系统。当我们实现了某项新功能、更新了某些工具或基础组件，或是把系统部署在某个新的平台上面时，就可能会遇到新系统无法正常运行的问题，此时如果旧系统依然正常，那么我们通常可以通过寻找（下面就会讲到如何寻找）或尽量缩小（参见第45条）新旧两个系统之间的差别来锁定问题的原因。
之所以能根据新旧系统间的差距来进行调试，其原因在于：尽管各人所经历的问题有所不同，但计算机的底层运作方式却是十分确定的，也就是说，同样的输入会产生同样的输出。因此，只要能够深入故障系统中，并对其进行足够的探查，我们就迟早能够找到相关的bug，从而揭示出该系统为什么会在行为上与正常系统有所不同。
其实有很多时候，系统的故障原因都会非常明确地出现在你面前，只要你肯打开程序的日志文件（参见第56条），就有可能发现里面有一条消息告诉你，clients.conf这个配置文件有错误：

在另外一些情况下，错误的原因可能会隐藏得比较深，此时你必须提升系统日志的详细程度（verbosity），才能把它暴露出来。
如果系统没有提供足够详细的日志机制，那我们就需要用追踪工具来梳理其运行时的行为。除了DTrace和SystemTap等通用的工具，还有一些专门的工具可以用来追踪对操作系统的调用（strace、truss、Procmon）、对动态链接库的调用（ltrace、Procmon）、网络包（tcpdump、Wireshark）以及SQL数据库调用（参见第58条）。有很多Unix应用程序（如R Project）是借助复杂的shell脚本来启动的，因此可能会以极其隐晦的方式出错。针对这样的错误，在大多数情况下，我们都可以通过给相应shell传入-x选项的办法来进行追踪，这样得到的数据通常很庞大，所幸现在的系统都有很大的容量能够存放这两份日志（以其中一份表示那个可以正常运作的系统，另一份表示出现了故障的系统），而且都有很强的CPU能够对其进行处理与比较。
就系统的操作环境而言，我们应该尽量确保这两个系统拥有相似的环境，因为这样能够更加方便地对比日志文件或追踪信息，有时甚至可以直接找到造成bug的原因。我们可以先从一些较为明显的部分入手，例如，程序的输入以及命令行参数等。与早前所说的原则一样，我们也要亲自进行验证，而不能想当然地接受假设。例如，应该在两个系统的输入文件之间进行对比，如果它们都比较庞大并且离得比较远，那可以考虑对比它们的MD5校验和。
然后，我们应该把重点放在代码上。首先对源代码进行对比，我们可能要挖得深一些才能找到bug所在的地方。可以通过ldd命令（适用于Unix系统）或是带有/dependents选项的dumpbin命令（适用于Visual Studio）来查看与每个可执行文件有关的动态程序库，并通过nm命令（适用于Unix系统）、带有/exports/imports选项的dumpbin命令（适用于Visual Studio）或javap命令（适用于以Java语言开发出来的程序）来查看程序所定义和使用的符号。如果你确信问题肯定出现在代码中，但又看不出明显的差别，那么可能就要往更深的层次去探查了，也就是需要对比由编译器所生成的汇编代码（参见第37条）。
然而在进行更深层次的探查之前，应该先考虑一下有没有其他因素会影响程序的执行情况，环境变量就是这样一个容易忽视的因素，即便是没有特权的用户，也依然可以通过设置环境变量来破坏程序的正常执行。另一个因素是操作系统。与运行着正常程序的那个操作系统相比，故障程序所在的这个操作系统，可能新了10年或是旧了10年。此外，也要考虑编译器、开发框架、第三方链接库、浏览器、应用程序服务器、数据库系统以及其他一些中间件。至于怎样在这么多的因素中确定问题的根源，则是我们接下来要讲的话题。
大多数情况下，我们都是在一堆干草里面找一根针（大海捞针），因此应该尽量使这堆干草变得小一些，于是，就要花时间来构造一个既能体现bug，又最为简单的测试用例（参见第10条）。（另外一种办法是把要找的针变大一些，也就是命令这个有bug的程序输出更多的信息，然而这种做法很少能起到比较好的效果。）简明的测试用例可以缩短日志文件与追踪信息的长度并减少处理时间，从而令调试工作变得更加轻松。要想有条理地简化测试用例，我们可以在确保能够重现bug的前提下，逐渐删除用例中的元素或系统中的配置选项，直到删至最简。
如果正常系统和故障系统的区别位于源代码中，那么有一种很实用的办法，就是对这两个版本之间的历次修改进行二分搜索（binary search），以确定问题所在。例如，如果正常系统的版本号是100，而故障系统的版本号是132，那我们首先测试116版的程序是否正常，如果116版正常，那就判断它与132版之间的中点，也就是124版是否正常，如果116版有错，则判断它与100版之间的中点，也就是108版是否正常，并依此类推。每次修改完程序之后，我们都应该把代码单独提交到版本控制系统里面，这样做的好处之一，就是使得我们能够进行二分搜索。某些版本控制系统提供了可以自动执行搜索的命令，例如，Git就提供了git bisect命令（参见第26条）。
还有一个很有效的办法，是用Unix工具对比两份日志文件（参见第56条），以找出其中与bug有关的区别。我们在这种情况下所使用的工具，是diff命令，它可以显示出两份文件的不同之处。然而日志文件经常会在无关紧要的地方表现出差别，这会把那些与bug真正有关的差别给掩盖掉，于是，我们可以考虑用各种办法来过滤干扰因素。例如，如果每一行开头的几个字段，都是时间戳与进程ID等信息，那我们就可以用cut或awk命令来把这些大同小异的信息裁掉。下面这条命令可以对Unix系统的messages日志文件进行裁切，它会从每一行的第4个字段开始显示其内容：

只把你感兴趣的那些事件选出来就可以了，例如，如果你只对打开的文件感兴趣，那么可以用grep'open('这样的命令来进行筛选。你也可以用grep-v gettimeofday等命令来把对自己有干扰的文本行过滤掉（例如，在Java程序里面，会有成千上万次与获取系统时间有关的调用）。此外，还可以在sed命令中指定适当的正则表达式，以便把文本行中自己不感兴趣的那一部分裁掉。
最后再讲一个高级的实用技巧：如果两份文件各自的排序方式无法使diff命令给出有效的对比结果，那我们可以把感兴趣的字段提取出来，对其进行排序，然后用comm工具在排好顺序的两个集合中找寻不同的元素。例如，如果我们想对比t1和t2这两份追踪信息，以找出有哪些文件只出现于t1中，那么可以在Unix的Bash shell中输入下列命令，它会在包含字符串open(的那些文本行里面提取表示文件名的第二个字段，并在提取出来的这两个集合之间寻找差别：

两对小括号里面的那两个元素，会分别生成两份有序列表，列表中的每一项都是一个传给open的文件名，而comm命令（这个命令用来在两份列表之间寻找共同的元素）则以这两份列表为输入值，并把只出现在第一份列表中的内容列出来。
要点
在能够正常运作的系统与出现故障的系统之间对比，找出行为上的区别，以求发现故障的原因。
影响系统行为的所有因素都要考虑到，包括代码、输入、调用时的参数、环境变量、服务以及动态链接库。