跳至主要內容

GDB：从暂停现场、线程栈到 Core 与远程调试

高谷深陵大约 17 分钟约 5180 字

凌晨的订单进程没有退出，却不再消费消息。监控只告诉你队列在增长，日志停在一次普通的锁请求；重启能恢复服务，也会把线程当时持有什么锁、等待什么地址、局部变量是什么全部抹掉。工程师连上机器执行 gdb -p PID，进程随即停住，健康检查又把实例摘流。调试器获得了现场，也改变了现场。

GDB 的价值不是“能打断点”，而是把可执行文件、调试符号、进程或 Core、线程、栈帧、寄存器和内存组织成可核验的状态。它同样不是只读观察器：attach 会暂停目标，断点会改变执行时序，表达式可能调用目标函数，写内存或寄存器更会直接改写故障。可靠的调试链必须同时回答看到的状态属于哪个构建、动作造成多长暂停、证据能否离线复核，以及退出后还留下了什么。

GDB 启动 attach 线程栈 Core Build ID gdbserver 自动加载与退出治理知识海报
GDB 运行时调试与现场证据链把 executable、Build ID、symbols、live process、thread/frame 与 core snapshot 绑定起来，在暂停预算、远程边界和清理证据约束下完成调试。高清原图

先确认拿到的是哪一个 GDB

Linux 发行版仓库适合日常安装，GNU GDB 正式发布入口适合需要特定 target、Python 或 debuginfod 能力的工具链基线。包名和拆分方式由发行版决定：Debian/Ubuntu 系通常把主程序放在 gdb，RHEL/Fedora 系也提供 gdb，C 库和第三方库的调试符号常在独立 debug 包或符号仓库中。安装动作应经过发行版签名仓库；若从 GNU 源码构建，则保存源码包、签名验证结果、configure 参数和编译器版本。不要因为命令名存在，就假定 Python、debuginfod、目标架构或压缩调试段都已启用。

在已配置官方签名仓库的开发机上，常见安装入口如下；企业镜像和目标发行版若改了包名，应以自己的仓库元数据为准：

# Debian / Ubuntu 系开发机
sudo apt-get update
sudo apt-get install -y gdb gcc make binutils

# Fedora / RHEL 系开发机
sudo dnf install -y gdb gcc make binutils

生产主机不必常驻完整编译工具链。更稳妥的形态是受控调试镜像或分析机持有 GDB、符号和源码，目标节点只在批准窗口提供进程、Core 或短时 gdbserver；这样能减少主机软件面，但仍不能绕过 attach 权限和证据传输治理。

安装后先记录二进制来源与构建能力：

command -v gdb
gdb --version
gdb --configuration
gdb -q -nx -batch \
  -ex 'show version' \
  -ex 'show configuration'

# 可选能力分开探测，避免一个缺失项掩盖其他结果
if gdb -q -nx -batch -ex 'python import sys; print(sys.version)'; then
  python_probe_status=0
else
  python_probe_status=$?
fi
printf 'python probe exit=%s\n' "$python_probe_status"

if gdb -q -nx -batch \
  -ex 'show debuginfod enabled' \
  -ex 'show debuginfod urls'; then
  debuginfod_probe_status=0
else
  debuginfod_probe_status=$?
fi
printf 'debuginfod probe exit=%s\n' "$debuginfod_probe_status"

前三条基线命令预期得到实际版本、host/target 和 configure 参数，并以 0 退出。后两组是能力探针：能力存在且命令成功时退出码为 0；python 或 debuginfod 命令不存在时，GDB 的 -batch 会因命令错误以非零状态退出，这个非零是“当前构建缺少该能力”的证据，不应被写成整套 GDB 安装失败。Python 行若报告 Undefined command: "python" 或 Python 支持不可用，应回到 GDB 的构建选项和发行版拆包检查，不要先怪 pretty-printer。show debuginfod enabled 不存在，也可能意味着版本较旧或构建时没有 libdebuginfod。GNU 正式版手册的 batch 模式说明 明确区分命令错误与被调试程序的退出状态；只有显式使用 -return-child-result 时，二者才按该选项约定关联。版本治理应固定团队真正验证的发布线，不把滚动开发手册页眉当成稳定版号；升级时比较 gdb --configuration，因为同一版本号的两份构建也可能能力不同。

建一个既会崩溃也会死锁的实验进程

下面的实验只应放在无生产数据的隔离 Linux 工作目录。crash-lab.c 用参数选择确定性空指针崩溃或双锁等待；barrier 保证两个线程都先持有第一把锁，再等待对方的锁，使线程现场可重复观察。

#include <pthread.h>
#include <stdio.h>
#include <string.h>

static pthread_mutex_t left = PTHREAD_MUTEX_INITIALIZER;
static pthread_mutex_t right = PTHREAD_MUTEX_INITIALIZER;
static pthread_barrier_t ready;
static volatile int watched_counter = 0;

static void bump_counter(void) {
    watched_counter += 1;
}

static void *lock_left_then_right(void *unused) {
    (void) unused;
    pthread_mutex_lock(&left);
    pthread_barrier_wait(&ready);
    pthread_mutex_lock(&right);
    return NULL;
}

static void *lock_right_then_left(void *unused) {
    (void) unused;
    pthread_mutex_lock(&right);
    pthread_barrier_wait(&ready);
    pthread_mutex_lock(&left);
    return NULL;
}

static void crash_now(void) {
    volatile int *address = NULL;
    *address = 39;
}

int main(int argc, char **argv) {
    if (argc == 2 && strcmp(argv[1], "crash") == 0) {
        crash_now();
        return 0;
    }

    if (argc == 2 && strcmp(argv[1], "watch") == 0) {
        for (int i = 0; i < 8; ++i) {
            bump_counter();
        }
        return watched_counter == 8 ? 0 : 1;
    }

    pthread_t a, b;
    pthread_barrier_init(&ready, NULL, 2);
    pthread_create(&a, NULL, lock_left_then_right, NULL);
    pthread_create(&b, NULL, lock_right_then_left, NULL);
    pthread_join(a, NULL);
    pthread_join(b, NULL);
    return 0;
}

同时构建便于教学的未优化版本和接近发布形态的优化版本，并记录身份：

mkdir -p build/debug build/optimized evidence
cc -g3 -O0 -fno-omit-frame-pointer -pthread crash-lab.c -o build/debug/crash-lab
cc -g1 -O2 -pthread crash-lab.c -o build/optimized/crash-lab
sha256sum build/debug/crash-lab build/optimized/crash-lab | tee evidence/binaries.sha256
readelf -n build/debug/crash-lab | sed -n '/Build ID/p'
readelf -n build/optimized/crash-lab | sed -n '/Build ID/p'

两个产物应有不同摘要，通常也有不同 Build ID。-g 决定是否生成调试信息，-O0 只是让教学现场更直观；生产问题常来自优化构建，变量显示 <optimized out>、函数被内联或尾调用消失都不等于变量从未存在或函数从未执行。保留优化产物本身及其匹配符号，比临时重编一份 -O0 二进制更重要。

启动式调试先建立最小正确链

用安全基线启动 GDB：-nx 不读取初始化文件，早期 -iex 在装载对象文件前关闭自动加载和联网取符号。处理来源不明的 executable、core、源码目录或符号包时，这比进入 GDB 后再关开关更早。

gdb -q -nx \
  -iex 'set auto-load off' \
  -iex 'set debuginfod enabled off' \
  --args ./build/debug/crash-lab crash

会话中执行：

(gdb) start
(gdb) info files
(gdb) break crash_now
(gdb) continue
(gdb) bt
(gdb) info locals
(gdb) continue
(gdb) bt full

start 会创建 inferior 并运行到 main 附近，动态加载器、全局构造器和其他早期代码可能已经执行；需要从程序第一条机器指令观察时才用 starti。命中 crash_now 断点后，调用栈应包含 crash_now 与 main；再次继续应收到 SIGSEGV，当前帧指向写空地址的语句。若只出现 ??、地址而没有文件行，先检查正在调试的 executable、Build ID 和 debug info，不要根据一个猜测的源码版本解释地址。

反向实验可对优化产物运行同样流程。预期可能仍定位到函数或行，但局部变量、内联边界和栈形状与 -O0 不同。这一差异证明“源码看起来相同”不能替代产物身份。另一个重要边界是表达式：print local_value 通常读取当前状态，而 print some_function() 会在被暂停进程中执行函数，可能拿锁、分配内存、发请求或改全局状态。生产现场默认禁止函数调用型表达式，除非有明确变更授权和回退条件。

断点回答“执行是否到达某个位置”，watchpoint 回答“哪条机器指令读写了某段存储”。对 watch 模式建立一条可重复的写监视链：

(gdb) set args watch
(gdb) break bump_counter
(gdb) run
(gdb) info breakpoints
(gdb) watch watched_counter
(gdb) info watchpoints
(gdb) continue
(gdb) x/i $pc
(gdb) bt
(gdb) print watched_counter

break bump_counter 应解析到实际 location；第一次进入函数后，watch watched_counter 才能把表达式解析为稳定地址。继续运行时，硬件 watchpoint 应在写入发生的机器指令附近停止，并显示旧值和新值。watch 监视写，rwatch 监视读，awatch 监视读写，但后两者依赖目标硬件和远程 stub 能力。硬件寄存器数量、地址对齐与监视宽度都有限，过宽对象或 watchpoint 过多会被拒绝；GDB 若退化成软件 watchpoint，通常需要单步并反复求值，性能与时序扰动会显著上升。

反向实验先执行 set can-use-hw-watchpoints 0，再删除并重建该 watchpoint。若目标不支持软件 watchpoint，命令应明确失败；若支持，停止位置和耗时可能与硬件模式不同。这个差异要作为能力证据保存，不能把“命令编号存在”当成监视已经生效。实验结束执行 delete 并用 info breakpoints 确认临时 breakpoint/watchpoint 均已消失；生产 attach 中不要为验证监视点而主动改写业务变量。

Attach 先计算暂停预算，再谈权限

启动死锁模式并记录 PID：

./build/debug/crash-lab >evidence/deadlock.stdout 2>&1 &
target_pid=$!
printf '%s\n' "$target_pid" | tee evidence/deadlock.pid
sleep 1
ps -o pid,stat,etime,cmd -p "$target_pid"

在第二个终端以同一用户 attach：

target_pid=$(cat evidence/deadlock.pid)
gdb -q -nx -p "$target_pid"
(gdb) info inferiors
(gdb) info threads
(gdb) thread apply all bt full
(gdb) detach
(gdb) quit

attach 成功时目标首先被停止；默认 all-stop 模式下，一个线程停住会使全部线程停止。线程栈应看到两个工作线程分别位于 mutex 等待路径，一个从 lock_left_then_right 进入，另一个从 lock_right_then_left 进入，主线程等待 pthread_join。这能证明采样时存在互相等待的结构，却不能仅凭单次栈证明等待持续了多久、此前谁先取得锁或所有数据竞争的因果。需要重复采样、锁 owner/waiter、运行时事件或 rr 等补充证据。

thread apply all bt full 会打印所有线程的局部变量，真实进程中可能出现令牌、请求体、文件路径和客户数据。输出写入文件前就应确定访问组、保存目录、脱敏责任和保留期。GDB 第一列 thread ID 是调试器标识，可能形如 2.1；Linux LWP/TID 是另一列，脚本不能把二者无条件互换。

若 attach 失败，典型输出是 ptrace: Operation not permitted。它不只表示 UID 不同，按下面顺序做只读检查：

cat /proc/sys/kernel/yama/ptrace_scope
grep -E '^(Name|TracerPid|Uid|Gid):' "/proc/$target_pid/status"
readlink "/proc/$target_pid/ns/user"
readlink "/proc/$$/ns/user"

还要考虑目标是否 dumpable、是否已有 tracer、capability、user/PID namespace 以及 SELinux、Yama 等 LSM。不要把 sudo gdb、--privileged 或全局写 ptrace_scope=0 当默认修复；它们扩大的是整机进程读取和修改面。优先让调试器成为目标的父进程，或在同一受控 namespace 和 UID 下复现实验；确需 CAP_SYS_PTRACE 时只授予短时调试容器或专用身份，并在退出后撤销。

完成 live 检查必须显式 detach。它会释放并继续运行 attach 的目标；对由 GDB 启动的 inferior，quit、kill 和 detach 的语义不同，自动化脚本不能依赖交互提示的默认回答。

Core 把暂停窗口变成离线窗口

崩溃时由内核或 systemd 采集的 Core，以及 live 进程上由 generate-core-file/gcore 产生的快照，都保存寄存器和选定内存映射；它们不保存此前的调度、系统调用历史，也不能像 live inferior 一样继续执行。对暂停预算很短、需要跨团队复核或不允许长期 attach 的现场，Core 往往更合适。

在死锁会话中可主动生成快照：

(gdb) show use-coredump-filter
(gdb) show dump-excluded-mappings
(gdb) generate-core-file evidence/deadlock.core
(gdb) detach

离线打开时同时指定匹配 executable：

gdb -q -nx \
  -iex 'set auto-load off' \
  -iex 'set debuginfod enabled off' \
  ./build/debug/crash-lab evidence/deadlock.core
(gdb) info files
(gdb) info threads
(gdb) thread apply all bt full
(gdb) info sharedlibrary

预期仍能切换线程与栈帧，但 continue 不会恢复原进程。Linux 上主动快照通常参考 /proc/PID/coredump_filter 并尊重 VM_DONTDUMP；某段映射缺失可能是采集策略，不一定是文件损坏。Core 还可能是 sparse file，ls -lh 的逻辑大小与 du -h 的实际占用不同，复制工具若展开空洞会突然增加传输和存储成本。

错误符号必须作为一等失败处理

最危险的不是“完全没有符号”，而是错误 executable 或 debug 文件仍给出一条看起来合理的栈。先比较 Core 对应产物与候选文件的 Build ID、摘要和构建记录：

readelf -n build/debug/crash-lab | sed -n '/Build ID/p'
readelf -n build/optimized/crash-lab | sed -n '/Build ID/p'
sha256sum -c evidence/binaries.sha256
gdb -q -nx -batch \
  -iex 'set auto-load off' \
  -iex 'set debuginfod enabled off' \
  ./build/debug/crash-lab evidence/deadlock.core \
  -ex 'info files' -ex 'thread apply all bt'

反例是故意用 build/optimized/crash-lab 打开由 debug 产物生成的 Core：

gdb -q -nx -batch \
  -iex 'set auto-load off' \
  -iex 'set debuginfod enabled off' \
  ./build/optimized/crash-lab evidence/deadlock.core \
  -ex 'info files' -ex 'thread apply all bt'

GDB 可能明确警告 core 与 executable 不匹配，也可能显示错误地址、??、异常帧或误导行号。这个反例甚至可能以 0 退出，因为警告和错误身份不一定构成 GDB 命令错误；因此退出码只能证明批处理命令完成，不能证明符号匹配。无论输出是否“像真的”，Build ID 或摘要不一致就应停止解释。Build ID 是 ELF 产物与调试资源的关联键，不是源码 commit、构建参数或可信签名；证据包还要绑定源码提交、编译器、优化/LTO 参数、依赖 rootfs 和产物摘要。

分离符号可按 debuglink 或 .build-id/ab/cdef....debug 布局保存。使用 debuginfod 时，先检查 show debuginfod urls，只配置批准的 HTTPS 入口，并确认内部服务是否联邦外部上游。查询会暴露 Build ID，下载的 debuginfo 和 source 会进入本地缓存；非交互 GDB 不应被假定为自动下载。离线事故室更适合预先准备经校验的符号包和 sysroot，避免分析时把产物身份、源码路径或专有符号发送到未知服务。

自动加载脚本与 Python 具有 GDB 的权限

项目 .gdbinit、对象旁的 objfile-gdb.py、.debug_gdb_scripts 和 pretty-printer 都可能执行代码。GNU 正式版手册的 auto-loading 说明 也把这些入口视为自动执行面。auto-load safe-path 只是路径允许列表，不是签名校验或沙箱；把 /、整个 home 或低权限用户可写工作区设为 safe path，等于允许这些位置的脚本以 GDB 身份执行。

先用基线命令确认没有自动加载，再只允许经过评审的只读目录：

gdb -q -nx -iex 'set auto-load off' ./build/debug/crash-lab
(gdb) info auto-load python-scripts
(gdb) show auto-load safe-path

需要项目 pretty-printer 时，将固定版本安装到只有维护者可写的目录，记录脚本摘要与 owner，再精确配置 safe path。GDB Python API 也不是供任意线程并发调用的普通库；扩展线程不能直接调用要求 GDB 主线程上下文的 API。高权限 attach 会话中加载未知脚本，风险等同于以该权限执行未知程序。

远程调试在传输边界上做取舍

gdbserver 把目标进程控制交给远端 GDB，GNU 正式版服务端说明 明确警告它没有内建安全机制。直接监听 :2345 只适合有网络隔离、来源 ACL 和短时回收的实验；--once 只改变首次连接后的监听生命周期，不会增加认证、授权或加密。更稳妥的入口是经 SSH 标准输入输出承载 remote protocol：

(gdb) file ./build/debug/crash-lab
(gdb) target remote | ssh -T debug-user@target.example \
  gdbserver - /srv/debug/crash-lab crash

目标端 gdbserver 不需要完整符号，host GDB 需要匹配 executable、debug info、源码和 target sysroot。容器或异构主机上的共享库与宿主不同，应准备目标 rootfs：

(gdb) set sysroot /srv/sysroots/release-candidate
(gdb) set solib-search-path /srv/sysroots/release-build/lib
(gdb) info sharedlibrary

普通 target remote 连接后由 gdbserver 启动或 attach 目标，GDB 端不能再使用 run 或 attach；remote 与 extended-remote 的正式版对照 说明后者才支持保持连接后重新 run 或 attach，断开和 server 生命周期也不同。远端 attach 应在目标侧显式执行 gdbserver --attach - PID，或使用 --multi 配合 target extended-remote 后由 GDB 选择 PID；两种方式不能混成一套命令。连接后还要用 info files、info sharedlibrary、maintenance info sections 与目标部署清单核对 executable、共享库、架构和 Build ID，不能因协议连接成功就默认 host 符号属于 remote 进程。

选择远程 live 调试时，优势是能继续、设断点和观察动态变化，代价是持续控制权、网络入口和暂停影响；选择 Core 离线分析时，优势是可复制复核和不再影响进程，代价是没有历史、不能继续且可能缺页。rr 能提供受支持边界内的记录回放，但受 Linux、CPU、内核、性能计数器和外部共享状态限制，不能作为所有现场的通用替代。

把调试证据接进项目构建

项目发布流水线应同时产出运行二进制、分离符号、构建清单和来源映射，而不是故障发生后重新编译。一个 ELF 流水线可在保留原始未剥离产物的受控阶段生成运行文件和 debug 文件：

objcopy --only-keep-debug build/release/service build/symbols/service.debug
strip --strip-debug --strip-unneeded build/release/service
objcopy --add-gnu-debuglink=build/symbols/service.debug build/release/service
readelf -n build/release/service | sed -n '/Build ID/p'
readelf -n build/symbols/service.debug | sed -n '/Build ID/p'
sha256sum build/release/service build/symbols/service.debug >build/manifest.sha256

产物仓库以 Build ID 查找符号很方便，但发布清单仍需记录 commit、编译器和 linker 版本、目标架构、优化/LTO、依赖镜像或 sysroot 摘要。部署记录把进程镜像 digest 或包版本绑定到同一清单。事故脚本在执行 bt full 前先校验 Build ID；校验失败直接停止，不能用“只有这一份符号”作为继续依据。

团队还应把常用 GDB 命令做成无副作用、可评审的脚本：默认关闭 auto-load 与 debuginfod，不调用目标函数，不写内存，不修改断点命令中的业务状态；输出先写权限为 0600 的临时目录，再经脱敏进入工单。CI 可以验证测试程序的符号绑定和批处理回溯，不应对共享运行环境执行 attach。

容量、敏感数据与退出必须一起设计

一次全线程 bt full 可能泄露栈上的认证头、数据库口令、PII 和内部路径；Core 更接近一份进程内存快照，敏感等级通常不低于生产数据。符号文件和源码本身也可能包含专有类型、绝对构建路径和业务结构。三类资产不能因为“只是调试文件”而进入公开工单、个人网盘或无保留期的对象存储。

容量预算至少区分 Core 逻辑大小、实际块占用、压缩后大小、同一事故的副本数、符号/cache 体积和跨区域传输。大型进程可以通过采集策略排除不必要映射，但这会降低可分析性；应由故障类型决定保留哪些区域，并用实验确认关键线程栈、堆对象或映射仍在。到期删除要覆盖采集主机、分析机、跳板机、工单附件、对象存储版本、备份和 debuginfod 缓存，不能只删最初那一份文件。

实验结束后逐层清理并复查：

if kill -0 "$target_pid" 2>/dev/null; then kill "$target_pid"; fi
wait "$target_pid" 2>/dev/null || true
ss -ltnp | grep ':2345' || true
rm -f evidence/deadlock.core evidence/deadlock.pid evidence/deadlock.stdout
rm -rf build/debug build/optimized
find evidence build -maxdepth 2 -type f -print

最后一条只应列出明确决定保留的脱敏摘要或为空；若启动过 gdbserver，还要确认进程与监听端口关闭、SSH 隧道和短时账号撤销；若授予 capability、容器 namespace 入口或临时 RBAC，也要在对应控制面核销。可持续的 GDB 能力不是让更多人随时 attach，而是让正确构建的现场能在最短暂停内被采集、在离线环境被复核，并在生命周期结束时被完整销毁。

跳到正文