获取所有线程回溯所需的最小GDB核心转储方案问询

一、GDB生成有效栈回溯的必要条件 #

GDB要生成完整的线程栈回溯，必须拿到三类关键信息：

1. 线程寄存器状态：每个线程的RIP（指令指针）、RSP（栈指针）、RBP（帧指针）等寄存器值，这是回溯的起点——核心转储默认会包含这部分，哪怕coredump_filter设为0x0也不会丢失。
2. 栈内存区域：栈里保存着函数调用的返回地址、栈帧链，没有这段内存，GDB根本没法顺着栈帧往上追溯，这就是设0x0时回溯中断的直接原因。栈属于匿名私有映射（对应coredump_filter的位0），但这类映射还包含堆内存，这也是设0x1后core仍有3.8GB的原因——堆占了绝大多数空间。
3. 进程内存映射清单：记录了可执行文件、共享库的加载地址范围，GDB结合本地的可执行文件和共享库文件，就能把内存地址转换成对应的函数名。这部分信息是核心转储ELF头的默认内容，不需要额外转储共享库的内存段。

二、能否过滤掉所有非必要内容？ #

完全过滤（0x0）肯定不行，必须保留栈内存。但我们可以不用转储整个匿名私有映射（堆+栈），只保留栈内存就能满足回溯需求——但coredump_filter的位是按内存类型划分的，没法单独区分栈和堆（二者同属匿名私有映射）。

不过有两种折中方案：

1. 压缩核心转储：设置coredump_filter为0x1，同时修改core_pattern让系统自动压缩core文件：

   echo "core.%p.%t.gz" > /proc/sys/kernel/core_pattern
   

   3.8GB的未压缩core，压缩后通常能降到几百MB，大幅降低存储和传输成本。
2. 手动导出栈内容：用GDB直接导出每个线程的寄存器和栈内存，跳过堆和其他无关区域：

   gdb --pid $PID --ex "set logging file stack_backtrace.txt" --ex "set logging on" --ex "thread apply all info registers" --ex "thread apply all x/2000x \$sp" --ex "q"
   

   生成的文件只有几MB，之后可以结合本地可执行文件，用GDB手动解析或写脚本批量处理。

三、更优的栈回溯获取方法 #

如果不是必须保留核心转储，这些方法比生成core再分析高效得多：

1. 本地GDB直接生成回溯：如果能直接在目标机器上操作，跳过core转储步骤，直接让GDB attach后输出回溯：

   gdb --pid $PID --ex "thread apply all bt full" --ex "q" > backtrace.log
   

   全程只生成几KB到几MB的日志文件，速度快，无存储压力。
2. 用perf工具采样回溯：无需attach进程，对生产环境进程影响极小，适合持续采样：

   # 采样10秒，生成栈回溯数据
   perf record -p $PID -g -- sleep 10
   # 解析成可读的回溯日志
   perf script > perf_backtrace.log
   

3. 远程执行GDB命令：如果目标机器是远程的，用ssh直接执行GDB命令并把日志传回本地，比传几百GB的core文件快几个数量级：

   ssh user@remote-host "gdb --pid $PID --ex 'thread apply all bt' --ex 'q'" > remote_backtrace.log
   

内容的提问来源于stack exchange，提问作者Maydaer