前端网站做中 英文,推广赚钱的app,上海免费做网站,淘宝客做连接网站吗本节书摘来自华章出版社《Effective Debugging#xff1a;软件和系统调试的66个有效方法》一书中的第1章#xff0c;第1.5节#xff0c;作#xff3b;希#xff3d;迪欧米迪斯斯宾奈里斯#xff08;Diomidis Spinellis#xff09;#xff0c;更多章节内容可以访问云栖社… 本节书摘来自华章出版社《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个字段开始显示其内容 只把你感兴趣的那些事件选出来就可以了例如如果你只对打开的文件感兴趣那么可以用grepopen(这样的命令来进行筛选。你也可以用grep-v gettimeofday等命令来把对自己有干扰的文本行过滤掉例如在Java程序里面会有成千上万次与获取系统时间有关的调用。此外还可以在sed命令中指定适当的正则表达式以便把文本行中自己不感兴趣的那一部分裁掉。最后再讲一个高级的实用技巧如果两份文件各自的排序方式无法使diff命令给出有效的对比结果那我们可以把感兴趣的字段提取出来对其进行排序然后用comm工具在排好顺序的两个集合中找寻不同的元素。例如如果我们想对比t1和t2这两份追踪信息以找出有哪些文件只出现于t1中那么可以在Unix的Bash shell中输入下列命令它会在包含字符串open(的那些文本行里面提取表示文件名的第二个字段并在提取出来的这两个集合之间寻找差别 两对小括号里面的那两个元素会分别生成两份有序列表列表中的每一项都是一个传给open的文件名而comm命令这个命令用来在两份列表之间寻找共同的元素则以这两份列表为输入值并把只出现在第一份列表中的内容列出来。要点在能够正常运作的系统与出现故障的系统之间对比找出行为上的区别以求发现故障的原因。影响系统行为的所有因素都要考虑到包括代码、输入、调用时的参数、环境变量、服务以及动态链接库。
