软件调试实战 pdf下载

　　《软件调试实战》是4位深谙软件调试之道的资深开发人员的实战经验总结，不仅讲述了简单的源代码调试，还涵盖了各个领域的常见的实际问题，包括程序链接、内存存取、并行处理和性能分析。后几章讨论了静态检查器，介绍了一些较好地运用了调试技巧的代码编写方法。书中讲述的调试技术不仅可以用于C／C++程序，还可以用于其他语言编写的程序。
　　软件调试是软件开发中令人苦恼的环节。反复思考每个假设，反复斟酌从需求到实现的每个步骤，将耗费大量时间。糟糕的是，调试根本无法预测，我们永远无法知道修复一个bug需要多长时间，

　　《软件调试实战》主要讲述C/C++程序的调试和分析，书中的调试技术也可以应用于其他语言编写的程序。《软件调试实战》在讲述简单的源代码分析和测试的基础上，讲述了现实的程序中经常遇到的一些问题（如程序链接、内存访问、并行处理和性能分析）并给出了解决方案。
　　《软件调试实战》适合软件开发人员、调试人员阅读和使用。

　　Thorsten Grotker，Ulrich Holtmann，Holger Keding，Markus Wloka4位作者均拥有德国或美国著名高等学府的博士学位，目前都任职于EDA（电子设计自动化）软件领导厂商Synopsys（新思）公司，分别担任研发主管、资深软件工程师等职位，负责开发编译器和调试工具，具有解决各种调试问题的丰富经验。

　　“如果我初开始调试程序时就能有这样一本书，该多好啊！我想我会屏息注视，看看这些调试工具将带给我什么惊喜，而且采纳书中的建议必然会节省大量手工调试的时间，可以将这些时间投入到其他工作中。譬如说，我可以使代码更可靠，这样后可能根本不必做任何调试了。”
　　——Andreas Zeller，GNU DDD创始人
　　“逐页阅读完本书之后，我必须承认这是我读过的好的一本软件调试图书，在很多方面都是其他书不能匹敌的……强烈推荐软件调试人员阅读。”
　　——（崩溃转储分

第1章 谁编写软件，谁制造bug（为什么需要本书）1

第2章 系统性调试方法3
2.1 为什么要遵循结构化的过程3
2.2 充分利用机会3
2.3 13条黄金规则5
2.3.1 理解需求5
2.3.2 制造失败6
2.3.3 简化测试用例6
2.3.4 读取恰当的错误消息6
2.3.5 检查显而易见的问题6
2.3.6 从解释中分离出事实7
2.3.7 分而治之7
2.3.8 工具要与bug匹配8
2.3.9 一次只做一项更改9
2.3.10 保持审计跟踪9
2.3.11 获得全新观点9
2.3.12 bug不会自己修复9
2.3.13 用回归测试来检查bug修复10
2.4 构建一个好的工具包10
2.4.1 工具箱11
2.4.2 每天运行测试，防止出现bug11
2.5 认清敌人——遇到bug家族13
2.5.1 常见bug13
2.5.2 偶发性bug13
2.5.3 Heisenbug13
2.5.4 隐藏在bug背后的bug14
2.5.5 秘密bug——调试与机密性14
2.5.6 更多读物15

第3章 查找根源——源代码调试器17
3.1 可视化程序行为17
3.2 准备简单的可预测的示例18
3.3 使调试器与程序一起运行18
3.4 学习在程序崩溃时执行栈跟踪21
3.5 学习使用断点21
3.6 学习在程序中导航22
3.7 学习检查数据：变量和表达式22
3.8 一个简单示例的调试会话23

第4章 修复内存问题27
4.1 C/C++中的内存管理——功能强大但很危险27
4.1.1 内存泄漏27
4.1.2 内存管理的错误使用28
4.1.3 缓冲区溢出28
4.1.4 未初始化的内存bug28
4.2 有效的内存调试器28
4.3 示例1：检测内存访问错误29
4.3.1 检测无效的写访问30
4.3.2 检测对未初始化的内存的读取操作30
4.3.3 检测内存泄漏31
4.4 示例2：对内存分配/释放的不完整调用31
4.5 结合使用内存调试器和源代码测试器33
4.6 减少干扰，排查错误33
4.7 何时使用内存调试器34
4.8 约束34
4.8.1 测试用例应该有很好的代码覆盖率34
4.8.2 提供更多计算机资源35
4.8.3 可能不支持多线程35
4.8.4 对非标准内存处理程序的支持35

第5章 剖析内存的使用37
5.1 基本策略——主要步骤37
5.2 示例：分配数组38
5.3 第1步：查找泄漏38
5.4 第2步：设置期望值38
5.5 第3步：测量内存使用39
5.5.1 使用多个输入39
5.5.2 在固定时间间隔停止程序39
5.5.3 用简单工具测量内存使用40
5.5.4 使用top40
5.5.5 使用WindowsTaskManager41
5.5.6 为testmalloc选择相关输入值42
5.5.7 确定机器上的内存是如何被释放的42
5.5.8 使用内存剖析工具43
5.6 第4步：查明大部分内存被哪些数据结构占用了44
5.7 综合练习——genindex示例45
5.7.1 核实没有大的内存泄漏46
5.7.2 估计内存使用46
5.7.3 测量内存使用46
5.7.4 查找使用内存的数据结构47

第6章 解决性能问题51
6.1 分步查找性能bug51
6.1.1 执行前期分析51
6.1.2 使用简单的时间测量方法52
6.1.3 创建测试用例52
6.1.4 使测试用例具有可再现性53
6.1.5 检查程序的正确性53
6.1.6 创建可扩展的测试用例53
6.1.7 排除对测试用例的干扰54
6.1.8 用time命令测量时可能会发生错误和偏差54
6.1.9 选择一个能够揭示运行时间瓶颈的测试用例55
6.1.10 算法与实现之间的差异56
6.2 使用剖析工具58
6.2.1 不要编写自己的剖析工具58
6.2.2 剖析工具的工作原理58
6.2.3 了解gprof59
6.2.4 了解Quantify63
6.2.5 了解Callgrind64
6.2.6 了解VTune66
6.3 分析I/O性能68

第7章 调试并行程序71
7.1 用C/C++编写并行程序71
7.2 调试竞争条件72
7.2.1 使用基本调试器功能来查找竞争条件73
7.2.2 使用日志文件来查找竞争条件74
7.3 调试死锁76
7.3.1 如何确定正在运行的是哪个线程77
7.3.2 分析程序的线程78
7.4 了解线程分析工具78
7.5 异步事件和中断处理程序80

第8章 查找环境和编译器问题83
8.1 环境变更——问题的根源83
8.1.1 环境变量83
8.1.2 本地安装依赖84
8.1.3 当前工作目录依赖84
8.1.4 进程ID依赖84
8.2 如何查看程序正在做什么84
8.2.1 用top来查看进程84
8.2.2 用ps来查找应用程序的多个进程85
8.2.3 使用/proc/来访问进程85
8.2.4 使用strace跟踪对操作系统的调用85
8.3 编译器和调试器也有bug87
8.3.1 编译器bug87
8.3.2 调试器和编译器兼容性问题88

第9章 处理链接问题89
9.1 链接器的工作原理89
9.2 构建并链接对象89
9.3 解析未定义的符号91
9.3.1 丢失链接器参数91
9.3.2 搜索丢失的符号91
9.3.3 链接顺序问题92
9.3.4 C++符号和名称改编93
9.3.5 符号的反改编94
9.3.6 链接C和C++代码94
9.4 具有多个定义的符号95
9.5 信号冲突96
9.6 识别编译器和链接器版本不匹配96
9.6.1 系统库不匹配97
9.6.2 对象文件不匹配97
9.6.3 运行时崩溃98
9.6.4 确定编译器版本98
9.7 解决动态链接问题100
9.7.1 链接或载入DLL100
9.7.2 无法找到DLL文件101
9.7.3 分析载入器问题102
9.7.4 在DLL中设置断点103
9.7.5 提供DLL问题的错误消息104

第10章 高级调试107
10.1 在C++函数、方法和操作符中设置断点107
10.2 在模板化的函数和C++类中设置断点109
10.3 进入C++方法110
10.3.1 用step-into命令进入到隐式函数中112
10.3.2 用step-out命令跳过隐式函数112
10.3.3 利用临时断点跳过隐式函数113
10.3.4 从隐式函数调用返回113
10.4 条件断点和断点命令114
10.5 调试静态构造/析构函数116
10.5.1 由静态初始化程序的顺序依赖性引起的bug117
10.5.2 识别静态初始化程序的栈跟踪118
10.5.3 在静态初始化之前连接调试器118
10.6 使用观察点119
10.7 捕捉信号120
10.8 捕获异常122
10.9 读取栈跟踪124
10.9.1 带调试信息编译的源代码的栈跟踪124
10.9.2 不带调试信息编译的源代码的栈跟踪124
10.9.3 不带任何调试信息的帧125
10.9.4 实际工作中的栈跟踪125
10.9.5 改编后的函数名称126
10.9.6 被破坏的栈跟踪126
10.9.7 核心转储127
10.10 操纵正在运行的程序128
10.10.1 修改变量130
10.10.2 调用函数131
10.10.3 修改函数的返回值132
10.10.4 中止函数调用132
10.10.5 跳过或重复执行个别语句133
10.10.6 输出和修改内存内容133
10.11在没有调试信息时进行调试135
10.11.1 从栈读取函数参数137
10.11.2 读取局部/全局变量和用户定义的数据类型138
10.11.3 在源代码中查找语句的大概位置139
10.11.4 走查汇编代码140

第11章 编写可调试的代码143
11.1 注释的重要性143
11.1.1 函数签名的注释144
11.1.2 对折中办法的注释144
11.1.3 为不确定的代码加注释144
11.2 采用一致的编码风格144
11.2.1 仔细选择名称145
11.2.2 不要使用“聪明过头”的结构145
11.2.3 不要压缩代码145
11.2.4 为复杂表达式使用临时变量145
11.3 避免使用预处理器宏146
11.3.1 使用常量或枚举来替代宏146
11.3.2 使用函数来替代预处理器宏148
11.3.3 调试预处理器输出149
11.3.4 使用功能更强的预处理器150
11.4 提供更多调试函数151
11.4.1 显示用户定义的数据类型151
11.4.2 自检查代码152
11.4.3 为操作符创建一个函数，以便帮助调试153
11.5 为事后调试做准备153

第12章 静态检查的作用155
12.1 使用编译器作为调试工具155
12.1.1 不要认为警告是无害的156
12.1.2 使用多个编译器来检查代码158
12.2 使用lint158
12.3 使用静态分析工具158
12.3.1 了解静态检查器158
12.3.2 将静态检查器检测到的错误减至（接近）零160
12.3.3 完成代码清理后重新运行所有测试用例160
12.4 静态分析的高级应用161

第13章 结束语163
附录A 调试命令165
附录B 工具资源167
附录C 源代码179
参考文献189

　　有了源代码调试器（以下简称调试器）以后，就可以逐行地走查源代码，查看程序的条件语句和循环语句都经过了哪些路径，显示哪些函数被调用了，以及显示目前正处于函数调用栈的什么位置。我们可以检查变量值，并在个别的代码行中设置断点，然后让程序运行，直至到达此行。这是在复杂程序中进行导航的便利方法。
　　调试器将显示程序都执行了哪些操作，这是修复任何bug的先决条件。如果代码是自己编写的，调试器可以帮助实现预期行为，即代码的功能。如果是别人编写的，调试将呈现出代码执行的动态视图，以补充静态代码检查。
　　本章将介绍基本的源代码调试器功能，并讲述如何用它们来查找C和C++程序中的bug。同时介绍独立于特定的计算机平台或工具。示例中将使用两个非常常见的调试器：GDB和VisualStudio。同时列出GDB和VisualStudio访问每个被讨论的特性的命令。为了节省篇幅，这里只展示节选的GDB输出并简要介绍Visual Studio如何输出结果，不会给出屏幕截图。
　　GNU调试器GDB代表从具有命令行接口的命令行解释器（command shell）运行的调试器。GDB与GCC编译器一起使用，已经被植入很多操作系统中，如Windows、Solaris、15NIX、Linux和用于嵌入式系统的操作系统。有关GDB的下载信息和文档，参见附录B.2.3。

　　在所有软件开发工作中，调试或许是最令人苦恼的。调试工作极易受到指责，因为技术失败即意味着做人失败，而且矛头直指调试人员，昭示出他们所犯下的错误。由于必须反复思考每个假设，反复斟酌从需求到实现的每个步骤，因此调试将耗费大量时间。最糟糕的是，调试还无法预测，我们永远无法知道修复一个bug需要多长时间，甚至根本不知道是否能够修复它。
　　问一下开发人员他们生活中最沮丧的时刻，大多数回答将与调试有关。也许现在正是深夜11点，你仍在忙着调试，正当对程序进行走查时，你的家人打电话给你，问你到底什么时候才能回家，而你只希望尽快放下电话，因为好不容易得到的观察结果和推断正要从脑中溜走。此时，你可能最后有两种选择：一是重新调试，二是过后再试图重修旧好。据我个人估计，调试是导致程序员离婚的第一大原因。
　　然而，调试也蕴含着乐趣，就像解出难题、猜出谜语或破获谋杀案一样令人激动，但前提条件是必须采用系统性的方式并配备正确的工具。这正是本书的用武之地。本书四位作者直接与那些固持己见的开发者对话，直截了当地提出解决调试问题的建议，并给出了真正快速的解决方案。无论是解决内存问题，调试并行程序，还是处理工具链引入的问题，本书都能够提供“急救措施”，书中的建议都是经过反复尝试和验证的。
　　如果我最初开始调试程序时就能有这样一本书，该多好啊！我想我会屏息注视，看看这些调试工具将带给我什么惊喜，而且采纳书中的建议，必然会节省大量手工调试的时间，并可将这些时间投入到其他工作中。譬如说，可以使代码更可靠，这样最后可能根本不必做任何调试了。
　　当然，这是专业编程的长期目标，即从一开始就编写正确的代码，通过某种确认或验证方法来杜绝所有错误（或至少检测到错误）。目前，断言和单元测试已经在提高程序可信度方面提供了很多帮助。未来可能会有一些用于行业级系统的成熟验证方法。我们现在尚未实现这样的方法，这可能需要很多年，而且当达到这个目标时，所实现的方法肯定不会适用于现在的编程语言。在处理当今的程序，特别是那些C和C++程序时，我们仍将在调试上花费一定时间——这正是本书的宝贵价值所在。