GDB / LLDB 高级调试技术 on Dorkytiger 的小屋

多线程调试

Mon, 01 Jan 0001 00:00:00 +0000

一、查看和控制线程

# 假设有一个死锁的多线程程序

(gdb) info threads
  Id   Target Id         Frame
  1    Thread 0x7f1 main() at main.cpp:10
  2    Thread 0x7f2 worker() at worker.cpp:23
  3    Thread 0x7f3 worker() at worker.cpp:45   ← 当前线程
* 4    Thread 0x7f4 worker() at worker.cpp:23

# * 号表示当前线程（正在调试的线程）
# 切换到线程 2：
(gdb) thread 2
[Switching to thread 2]
#0  worker() at worker.cpp:23
23        lock_b.lock();  // 线程 2 正在等 lock_b

# 看所有线程的调用栈：
(gdb) thread apply all bt

Thread 1 (main):
  #0 main() at main.cpp:10

Thread 2 (worker):
  #0  worker() at worker.cpp:23   ← 等 lock_b
  #1  std::thread::_Invoke() ...

Thread 3 (worker):
  #0  worker() at worker.cpp:30   ← 持有 lock_a
  #1  std::thread::_Invoke() ...

Thread 4 (worker):
  #0  worker() at worker.cpp:23   ← 等 lock_a
  #1  std::thread::_Invoke() ...

# 看到这个调用栈就知道死锁了：
# Thread 3 持有 lock_a，等 lock_b
# Thread 2 持有 lock_b，等 lock_a
# → 典型的 ABBA 死锁

二、调试无锁编程中的 Bug

无锁 Bug 的特点：不是每次都能复现，调试器里跑可能就不出现了。

反向执行调试（Reverse Debugging）

Mon, 01 Jan 0001 00:00:00 +0000

一、什么时候用

你的程序崩溃了，但你想看崩溃前的状态（比如变量是什么时候变成非法值的）。

# 启动调试
(gdb) record                     # 开始记录执行轨迹
(gdb) run                         # 运行程序
...
Program received signal SIGSEGV   # 崩溃了

# 现在可以反向执行
(gdb) reverse-continue            # 往回执行，停在崩溃点的"前一条语句"
(gdb) print ptr                   # 看到 ptr 是 nullptr 或野指针
(gdb) reverse-step                # 一步步往回走
(gdb) watch ptr                   # 观察 ptr 是什么时候改变的
(gdb) reverse-continue            # 继续往回走，停在 ptr 被修改的地方
(gdb) print caller               # 终于找到是谁把 ptr 改坏了

二、限制

GDB 的反向执行需要记录每条指令的执行轨迹。
内存占用：每 1 秒的执行记录大约需要 100MB+ 的内存。
所以只适合调试非常短的崩溃场景（从崩溃前 1 秒开始往回查）。

观察点（Watchpoint）

Mon, 01 Jan 0001 00:00:00 +0000

一、看变量值什么时候变了

// 一个典型的 Bug：某个全局变量被意外修改
int g_counter = 0;

void thread_a() {
    for (int i = 0; i < 100; i++) {
        g_counter++;   // 正常递增
    }
}

void thread_b() {
    // 某个地方错误地重置了 g_counter
    if (some_condition) {
        g_counter = 0; // ⚠️ 不该在这重置
    }
}

(gdb) watch g_counter             # g_counter 的值变化时停下
(gdb) continue
...

# 第一次触发：
Hardware watchpoint 1: g_counter
Old value = 42
New value = 0
# 线程 2 把 g_counter 从 42 改成了 0

(gdb) bt                          # 看调用栈，找到重置的代码位置
#0 thread_b() at bug.cpp:15       # 第 15 行就是罪魁祸首

其他观察点：

条件断点

Mon, 01 Jan 0001 00:00:00 +0000

// 一个循环中的 Bug：第 1000 次才出现
void process_data(std::vector<int>& data) {
    for (int i = 0; i < data.size(); i++) {
        // 只有在 i = 1000 时才崩溃
        if (i == 1000) {
            data[i] = data[2000];  // 如果 data 不够大就越界了
        }
    }
}

# ❌ 普通断点：要手动按 1000 次 continue
(gdb) break process_data

# ✅ 条件断点：直接停在崩溃的那次循环
(gdb) break process_data if i == 1000
(gdb) run
Breakpoint 1, process_data at main.cpp:15
(gdb) print data.size()          # 查看是否越界
$1 = 1500                        # size = 1500 < 2000，越界了！

线程条件断点：

Core Dump 分析

Mon, 01 Jan 0001 00:00:00 +0000

一、生成和应用场景

# 设置 core dump 文件大小（不限）
ulimit -c unlimited

# 运行程序，如果崩溃会生成 core 文件
./my_server

# 程序崩了，生成 core 文件
ls -la core.*
# 输出：core.12345   ← pid=12345 的 core dump

# 用 GDB 加载
gdb ./my_server core.12345

(gdb) bt
#0  handle_request() at server.cpp:123
#1  worker_loop() at threadpool.cpp:45
#2  ...
# 看到崩溃在第 123 行

(gdb) print request
# 看到请求数据，分析为什么会导致第 123 行崩溃

二、生产环境最有用的场景

你有一个线上服务，平时不好打断，但偶尔崩一次。

方案：
  1. 在生产环境设置 ulimit -c unlimited。
  2. 程序 crash 后 core 文件保留在磁盘上。
  3. 把 core 拉回开发机分析（注意不要包含用户敏感数据）。

  # 检查 core dump 是否正常生成
  cat /proc/sys/kernel/core_pattern
  # 常见配置：
  # /var/lib/systemd/coredump/core.%p  → systemd 管理的 core
  # core                                → 当前目录生成 core 文件

  # 如果看不到 core 文件，检查：
  ulimit -c              # 是不是 0（需要改成 unlimited）
  df -h /tmp             # 磁盘满了？core 文件写不进去

第五阶段总结

Mon, 01 Jan 0001 00:00:00 +0000

info threads → 看所有线程的调用栈
thread apply all bt → 找死锁（互相等锁）

reverse debugging → 看崩溃前的代码状态（占内存但有效）
watchpoint → 找"谁改了我的变量"
条件断点 → 在第 N 次循环崩溃时自动停

core dump → 线上崩了？不用怕，分析 core 就能定位原因