Bug 并不只出在你的 “代码” 中

计算机随时随地都在拒绝你

bash: curl: command not found

fatal error: 'sys/cdefs.h': No such file or directory
#include <sys/cdefs.h>

/usr/bin/ld: cannot find -lgcc: No such file or directory

make[2]: *** run: No such file or directory.  Stop.
Makefile:31: recipe for target 'run' failed

万能方法：假设你遇到的问题是别人也遇到的

• 但如果这是一个全新的问题？

计算机世界：一切皆可调试

程序 = 计算机系统 = 状态机

• 机器永远是对的

UNIX 世界里你做任何事情都是在编程

• “用编程语言把脑中所想传达给电脑”
• 刚才的问题都可以看成是程序/输入/配置有 bug

调试理论可以用于解决任何 “问题”

• curl: command not found
• 'sys/cdefs.h': No such file or directory
• Makefile:31: recipe for target 'run' failed

使用调试理论

Fault (程序/输入/配置错) → Error → Failure (可观测)

• 大部分 Error 和 Failure 都比较接近
  • 出错时，使用 perror 打印日志

“找不到问题” 的原因

• 出错原因报告不准确
• 程序执行的过程看不到
  • 那我们想办法 “看到” 状态机的执行过程就好了！

使用调试理论 (cont'd)

理解状态机执行：不是 “调试”，也是 “调试”

• ssh：使用 -v 选项检查日志
• gcc：使用 -v 选项打印各种过程
• make：使用 -nB 选项查看完整命令历史

调试：不仅是 “调试器”

• Profiler: perf - “采样” 状态机
• Trace: strace - 追踪系统调用

例子 (1): 找不到 sys/cdefs.h

'sys/cdefs.h': No such file or directory

• (这看起来是用 perror() 打印出来的！)
• 问题分析
  • #include = 复制粘贴，自然会经过路径解析
  • 明明 /usr/include/x86_64-linux-gnu/sys/cdefs.h 是存在的 (man 1 locate)

两种方法

• 日志 --verbose
• strace，直接看访问过的文件！

例子 (2): “Bug” 再现

装了 100 台一模一样的机器，但有一台出问题了

• 名字叫 “pm” 的 Kernel thread 占用 100% CPU
• LLM 有非常好的解题直觉

例子 (3): 无法安装的 Ubuntu

能看到 “转圈圈” 界面，但是 Unable to find a medium containing a live file system

回到调试程序

GDB：状态机查看器

• 允许我们控制执行流、检查状态
• 而且原生支持 Python
  • 因此拥有众多前端：gdb-gui, cgdb, pwndbg, gdb-dashboard, vscode, ddd, ..
  • (我觉得最好用的还是自己按需轻量定制)

使用 GNU Debugger

• GDB: 最常用的命令在 gdb cheat sheet
  • 打印贴在电脑前，调试时候看一遍，很快就大致记住了

我们的 GDB Linux Kernel Frontend

获得更好的调试体验

我们依旧需要 RTFM

• 否则我们甚至不知道 gdb 有多强大

Cheat Sheet 里没有的功能

• Text UI (我已经默认启动)
• Stack, optimized code, macros, ...
• Reverse execution
• Record and replay
• Scheduler

一点学习的建议 (和自我批评)

“时间压力” 带来的负面影响

• 总是被迫用肌肉记忆 (sub-optimal) 完成任务
• 高校教师的中年危机
  • 技术体系迅速与社区脱节
  • 变成 “道理都懂，啥也不会” 的键盘侠
  • 逐渐失去对技术发展方向的判断力

我们都需要一个 “跳出问题看问题” 的观察者

• 回顾刚才做过的事情
• 想一想能不能 “做得更好”
• AI Copilot!