Question

《Effective Debugging：软件和系统个调试的 66 个有效方法》

1 章 宏观策略

1条：通过事务追踪系统处理所有问题

开源的有 Bugzilla/Launch-pad/OTRS/Redmine/Trace 等，或者 JIRA 这种专有系统。

2条：在网上确切地查询你遇到的问题，以寻求解决灵感

简单、自足而且正确的范例（SSCCE）。搜索的时候用双引号可以更加精确搜索。搜不到可以去 stackoverflow 提问。

3条：确保前置条件和后置条件都满足

• 不应该为 null，却为 null 的值
• 数学函数的参数保证在定义域之内
• 对象， 结构体和数组内部细节
• 变量是否在范围之内
• 传递的数据结构是否正确，map 有没有包含预期的 key/val，链表是否可以正常遍历

4条：从具体问题入手向上追查 bug，或从高层程序入手向下追查 bug

• 程序崩溃。通常null/未初始化的值容易引发崩溃
• 程序冻结(freeze)：找出循环的终止条件和没有满足的原因
• 错误消息：grep 找到错误消息位置

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

影响因素：代码、输入、参数、环境变量、动态链接库

• 二分搜索
• 日志对比，grep/diff/comm

6条：使用软件自身调试机制

• 很多命令有 debug 选项。比如 sh -x， mysql explain

7条：试着多种工具构建软件，并放在不同环境执行

• 用多种编译工具构建软件，不同平台执行
• 考虑用更高级的语言重新实现

8条：工作焦点放在最重要问题上

高优先级的 bug：

• 数据丢失
• 数据安全
• 服务可用性降低
• 使用安全
• 程序崩溃或者冻结(freeze)
• 代码质量

低优先级：

• 支持遗留系统
• 向后兼容
• 有临时解决方案的问题
• 很少用的特性

2 章 通用的方法与做法

9 条：相信自己能把问题调试好

• 确信问题是可以排查的
• 流出足够的调试时间
• 安排好环境不受干扰。进入心流
• 睡一觉

• 学习环境和工具想关知识

  • 准备好健壮的最小测试用例
  • bug 重现自动化
  • 脚本分析日志文件
  • 了解 API 或语言特性的运作方式

10 条：高效地重建程序中的问题

sscce: 短小的(short)，自足的(self-contained)，正确的(correct)，范例(example)

• 准确重现
• 短小正确的范例
• 创建执行环境
• 用版本管理打上标记

11 条：修改完代码后，要能尽快看到结果

12 条：将复杂的测试场景自动化

通过脚本语言执行复杂的测试用例

13 条：使自己尽可能多地观察到与调试有关的数据

• 扩大日志显示区域

14 条：考虑对软件进行更新

• 更新后重新尝试你的代码，是否还会出错？
• 谨慎考虑第三方出问题的可能，你自己出问题的几率更高

15 条：查看第三方组件源代码，了解其用法

16 条：使用专门的监测和测试设备

协议分析工具，比如 wireshark, tcpdump 等监测网络数据包

17 条：使故障更加突出

• 迫使软件去执行可疑路径
• 提升某些效果的幅度，令其更加突出，以便于研究
• 对软件加压，暴露出负载下的状态
• 所有修改都要在版本管理下做

18 条：从自己的桌面计算机上调试那些不太好用的系统

19 条：使调试任务自动化

20 条：开始调试之前与调试完毕之后把程序清理干净

• 确保调试之前代码整洁
• 调试完毕，把临时改动还原回去，只把有用的代码提交上去（考虑单独用一个分支）

21 条：把属于同一个类型的所有问题全部都修复好

• 修复一个错误之后，搜索代码类似的地方是否有一样的问题需要修改

3章：通用的技术和工具

22 条：用 unix 命令行工具对调试数据进行分析

获取--筛选--处理--汇总

• nm 查看目标文件，获取哪些文件调用了 exit 函数。 nm -A *.o | grep 'U exit$'
• tar/jar/ar 查看压缩包内容
• cut 裁剪，sed 正则提取
• 大量文本使用 more/less
• xargs 命令输入端

23 条：掌握命令行工具的各种选项和习惯用法

• fgrep -lr 'Missing foo' 搜索所有包含错误消息的文件
• 对标准错误重定向以便于分析 ( 2>&1 )
• tail -f 监控持续增加的日志文件

24 条：用编辑器对调试程序时所需的数据进行浏览

• 使用编辑器搜索来查找拼写有误的单词
• 编辑文本突出不同点
• 编辑日志让其更加易读

25 条：优化工作环境

• 配置工具以提升效率。 alias/editor
• 通过版本控制共享 配置文件 (dotfiles)

26 条：用版本控制寻找 bug 发生的原因和经过

每一次修改都应该单独提交，而且要写上有意义的提交信息，如果有可能，还应该链接到对应的事务(比如 jira)上。

• git log somefile 查看某个文件变化
• git blame file
• git rev-list --all | xargs git grep extinctMethodName 在过去的版本中搜索指定字符串
• git log v1.2.3.. 只看某一个版本后开始发生的变化
• git rev-list -n 1 --before=2015-08-01 master 获取该日期之前最后一次提交所对应的 SHA hash
• git log --all --grep='Issue #1234' 搜索与某个事务有关的提交
• git show lcb634f6 指定展示某个 hash 的有关修改
• git diff v1.2.3..v1.3.2 显示两个版本之间的变化
• git checkout v1.1.0 回退到某个版本

二分查找并且锁定测试没有通过的版本

git bisect start V1.1.0 V1.2.3
git bisect run test.sh
git reset

如果正在做某一件事情，然后突然要去解决另外一件事，可以把当前的变更先隐藏，处理完别的事情之后再恢复。

git stash save interrupted-to-work-on-V1234
git stash pop

• 用 git 查看文件的修改记录，确定 bug 何时以何种方式引入
• 用 git 查看正在运行的版本和故障版本之间的区别

27 条：用工具监测多个独立程序构成的系统

• 主机健康。

  • cpu 内存 网络可达性 进程数量 登录用户数量 可以更新的软件 剩余磁盘容量 打开的文件描述符 网络和磁盘带宽 系统日志 安全性 远程访问

• 服务健康。
  • 数据库 邮件服务器 应用程序服务器 缓存 网络连接 备份 队列 消息传递 软件授权过期 web 服务器和目录

最好可以监测到：

• 能否正确处理整个流程
• 应用程序各个部分是否正常
• 某些关键指标是否正常。响应延迟，队列堆积，活跃用户数，失败交易，发生的错误和异常报告

Nagios 系统可以用来检测。

要点：

• 基础设施检查机制，各个部分是否正常
• 使自己可以在故障发生的时候迅速得到通知
• 查阅故障记录，发现规律或许可以帮你找出问题原因

4章：调试器的使用技巧

28 条：编译代码时把符号信息包含进来，以便于调试

发布的时候记得删掉这些信息。

• 大多数 unix 编译器支持用 -g 选项加入调试信息
• 调整，禁用优化选项

29 条：对代码进行单步调试

• 通过单步调试查看语句执行顺序和状态
• 跳过和 bug 无关部分
• 设置断点缩小范围

30 条：设置代码断点和数据断点

• 通过断点缩减范围
• 先在上游设置断点，然后再给需要的代码设置断点
• 针对异常或者程序退出的子程序设置断点
• 可以在调试器里终止没有响应的程序
• 数据断点锁定意外值导致的 bug

31 条：了解反向调试功能

• gdb 提供了 record reverse-next reverse-step
• 反向调试对性能影响很大

32 条：查看例程之间的相互调用情况

• gbd frame n 切换第 n 帧，up 和 down 上下移动
• 如果栈信息比较乱，代码可能写得有问题

33 条：查看变量和表达式的值，以寻找错误

• gdb 中叫做 pretty-printer
• python ，引入 pprint 模块
• python tutor 可视化执行过程

34 条：了解如何把调试器连接到正在运行的进程

# 先查找进程 pid
ps -u apache
gdb -p pid

链接到正在运行的进程之后可以打断其执行过程 (gdb:break)，还可以设置断点

35 条：了解 core dump 信息进行调试

unix 可以通过 kill-ABRT pid 发送 SIGABRT 信号，迫使其生成转储文件。终端里可以用 ctrl-\ 组合键发送这个信号。

36 条：把调试工具设置好

• cgdb/ddd 图形界面调试工具。
• gdbinit 文件
• gdb 可以运行 make 命令

37 条：学会查看汇编代码和原始内存

查看机器码错误

• 不必要的类型转换
• 误解了操作符优先级
• 无意中使用重载之后的操作符
• 没有配对的括号
• 错误的数值类型
• 不当的多态例程

gdb 执行 display/i$pc 显示反汇编之后的指令，然后可以用 stepi, nexti 单步调试。 info registers 查看寄存器的值， 通过 display$r0 或者 display$eas 持续显示某个寄存器。 使用 x/10xb&a 字节为单位，用十六进制显示 a 中的 10 个元素。

• 小端序(little-endian)，先保存最低有效位字节
• 大端序(big-endian，大端在前，也称为网络序)

5章：编程技术

38 条：对可疑代码进行评审，并手工演练这些代码

遵守约定，比如用括号理清楚运算符优先级。使用静态检查工具

需要关注的错误:

• 操作符优先级是否有误（尤其是位操作）
• 缺少必要的括号和 break 语句
• 多谢了分号
• 比较操作误写为赋值 (== vs =)
• 变量没有初始化，或是初始化为错误的值
• 循环中缺少必要语句
• off-by-one 错误
• 类型转化错误
• 拼写错误
• 缺少必要方法
• 特定编程语言陷阱

重点：

• 检查代码常见错误
• 用铅笔手工执行代码，验证是否正确
• 通过画图解析复杂的数据结构

39 条：审读代码和同事讨论

橡皮鸭技术(rubber duck technique)。 专业和礼貌的方式评审。

40 条：给软件增加调试机制

• 根据变异选项是否进入调试模式
• 通过命令行选项决定是否进入调试模式
• 发送 signal
• 通过命令行打开调试模式

41 条：添加日志(log)语句

关键例程的入口和出口、重要数据结构内容、状态的变化和用户操作的回应等，注意不要在生产环境启用

42 条：对软件进行单元测试

• 通过单测检查可疑例程，发现其中错误
• 使用合适的单测框架

43 条：用断言进行调试

从前置条件、不变条件、后置条件思考，设置断言验证

• 开头断言，验证 cpu 架构属性
• 例程入口断言，验证参数类型，是否有效(null)而且合理
• 例程出口验证是否正确
• 复杂的方法设置断言，验证状态
• 断言不会出错的 api
• 验证资源是否正确加在
• 验证复杂表达式的值
• switch 断言分支处理
• 断言数据结构的初始化是否正确

44 条：改动受测程序，验证推想

• 手工设定代码中的某些值，验证哪些取值是正确的，那些错误的
• 试着用其他的方式 替换 当前实现

45 条：尽量缩小正确范例与错误代码之间的差距

• 缩减你的代码使其与范例代码相符，或者逐渐修改范例代码，使其与你的代码相符，有利于找到错误原因

46 条：简化可疑代码

• 复杂的代码会增加调试工作量，可以临时简化，删除不必要的代码，使错误更加突出
• 大函数拆分成小部分，单独测试一部分
• 弃用某些复杂的算法、数据结构、程序逻辑。 精巧但是很复杂的代码，容易出 bug，对性能没有那么高要求的地方可以替换成简单的实现版本

47 条：将可疑代码替换成另一种编程语言编写

• 使用表达能力更强的语言改写难以修复的代码，减少可能出错的语句数量
• 移植代码到更好的编程环境，用更强大的调试工具解决
• 参照新代码修正旧代码

48 条：改善可疑代码的可读性与结构

混乱糟糕的代码容易滋生 bug。

装饰性的调整，代码重构，bug 修复工作要分开，并且要分别提交。

《重构》

49 条：清除 bug 根源，而不是仅仅消除症状

• 不要采用临时代码绕开程序表面症状，而是要查找 bug 深层原因并且修复
• 尽可能采用通用方式处理复杂情况，而不要只修复某些特例

6.章 编译时的调试技术

50 条：对生成的代码进行检视

• 查看自动生成的代码（字节码，汇编等），理解编译时和运行时问题
• 通过工具展示成容易阅读的形式

51 条：使用静态程序分析工具

lint 工具。最好加入到构建流程中

• null 进行解引用
• 并发错误和竞争条件
• 拼写有误的变量名
• 下标越界
• 错误的条件、循环、case，还有不会执行到的代码
• 未处理异常
• 没有用到的变量和例程
• 数学错误
• 代码重复
• 未实现接口
• 资源泄露
• 安全漏洞
• 特定编程语言问题

gcc -Wall

52 条：对项目进行配置，让程序以固定方式构建和运行

• gcc 随机选取符号名称
• 输入给编译器的文件顺序可能不同
• 软件中构建表示的时间戳会发生变化
• 哈希表或map 遍历后顺序不同。防止算法复杂度攻击
• 加密盐

53 条：对调试所用的程序库和构建代码执行环境进行配置

• 启用编译器所支持的运行时调试功能
• 构建过程中引入一些第三方库检查代码

7章：运行时调试技术

54 条：通过构建测试用例寻找错误

• 创建一个可靠并且最简单的测试用例
• 加入到回归测试防止重复犯错

55 条：让软件遇到问题时及早退出

测试环境中，及早退出有利于发现问题

• 添加并启动断言
• 配置程序库进行严格检查
• unix shell 开启 -e 选项，让 shell 在错误时候(return !=0)终止

56 条：检查日志文件

分析日志：

• gui 事件查看器
• 文本编辑器。比如 vim 可以用g/regular-ex-pression/d 删除无关的日志
• unix 工具过滤、汇总、筛选
• ELK、Logstash、loggly、Splunk

57 条：对系统和进程所执行的操作进行性能评测

• (unix)对于 cpu 来说，负载是否高于核心数量
• 内存，虚拟内存页面写入到磁盘的频率
• 网络 IO，丢包和重传。 iostat, netstat, nfsstat, vmstat 等工具
• 虚拟设备 IO，请求队列长度和操作延迟

58 条：追踪程序的执行情况

ltrace(追踪对程序库调用)，strace, ktrace, truss 追踪对操作系统调用

Dtrace。dtrace -n 'syscall:::entry'

59 条：使用动态程序分析工具

Valgrind 内存检查

8章：调试多线程代码

60 条：通过事后调试分析死锁问题

• gdb

# get pid
ps
# kill pid
kill -QUIT pid
# gdb deadlock core
>(gdb) info threads
>(gdb) thread 2
>(gdb) backtrace

• jdk jstack 排查 java 死锁

61 条：捕获并且重放

• 开启记录功能，反复运行直到重现
• 分析记录结果
• 程序放在调试器中运行，重放 bug
• 对程序该点的状态分析，找到错误原因

# 程序名 race
gdb_record race
(gdb) break main
(gdb) continue
(gdb) pin record on
(gdb) continue
(gdb) quit

可以用 replay 命令重放，程序按照和当初相同的顺序操作内存，也会表现出同样的错误行为。

replay pinball/log_0

gdb_replay pinball/log_0 ./race

62 条：用专门的工具探查死锁和竞争条件问题

• FindBugs: java -jar findbugs.jar -textui Counter.class
• Intel Inspector
• valgrind --tool=helgrind deadlock

63 条：把不确定因素隔离出来，或将其移除

• 行为不确定的代码和其他代码隔开
• 对这些代码适当的实现和配置，然行为变确定
• 移除法：用可以预测的实体替换掉难以预测的部分
• 创建 mock 对象

64 条：检查资源争用情况，以解决伸缩性问题

用 profiling 工具探查引发竞争现象的原因，以解决多线程代码中与可伸缩性有关的问题。

• Oracle Java Flight Recorder
• Inter VTune Amplifier

65 条：用性能计数器寻找伪共享问题

伪共享(false sharing)问题。cpu 核心的同步协议（缓存一致性协议），保证各线程总是可以看到一致的内存数据。 每个线程最好操作不同的内存区域(栈变量)，不要干涉其他线程所操作的内存数据

cpu 性能计数器。

用 perf 统计程序的末级缓存(last-level cache，简称 LLC)未命中次数。如果对缓存一致性协议的触发次数比较多， LLC-loads 就会随之增大。

per stat --event=LLC-loads ./sum-seq

66 条：考虑用高级的抽象机制重写代码

GNU parallel

使用更加高级的并发原语、编程语言、工具、框架等重新实现有 bug 的并发代码。