如何使用Golang GDB调试Core Dump_分析程序崩溃现场

go编译默认不嵌入dwarf调试信息，需加-gcflags=”all=-n -l”并避免-ldflags=”-s -w”；core文件需ulimit -c unlimited且未被core_pattern重定向；gdb无法直接识别goroutine，需结合info Threads与bt逐线程分析。

gdb 加载 core 文件时提示 “no debugging symbols found”

Go 编译默认不嵌入 DWARF 调试信息，gdb 读不到源码上下文和变量名，只能看到汇编和地址。这不是 gdb 问题，是 Go 构建配置缺失。

• 编译时加 -gcflags="all=-N -l"：禁用内联和优化，保留符号表（调试必需）
• 确保没用 -ldflags="-s -w"：这两个标志会剥离符号和调试段，直接导致 core 无法溯源
• 如果程序是用 go build 直接构建的，且没加调试参数，core 文件基本只能看栈帧地址，没法查 runtime.gopark 之后的 goroutine 状态

用 gdb 查看 Go panic 崩溃点 vs segfault 崩溃点

panic 和 segfault 在 core 中表现不同：panic 通常已进入 runtime.throw 或 runtime.fatalpanic，而 segfault 是信号中断，停在出错指令处（比如 mov %rax,(%rcx)）。处理方式也不同。

• 先执行 info registers 看 rip 和 rsp，再 x/10i $rip 确认是否真在非法内存访问点
• 如果是 panic，bt 里大概率看到 runtime.throw → runtime.fatalpanic → runtime.exit 链，此时要往上翻栈，找第一个用户代码帧（通常是 main.main 或 http.HandlerFunc）
• 用 goroutines 命令（需 go tool trace 或 delve 更好）——但原生 gdb 不识别 Go 协程；实际得靠 info threads + 切换 thread N + bt 逐个排查

core 文件没包含完整堆栈？检查 ulimit 和 kernel 设置

linux 默认可能限制 core 大小为 0，或只写部分内存页，导致 gdb 加载后 bt 只有 1–2 帧，甚至报 "Cannot access memory at address..."。

• 运行前设 ulimit -c unlimited（注意：仅对当前 shell 及子进程生效）
• 确认 /proc/sys/kernel/core_pattern 没重定向到管道或压缩程序（如 |/usr/lib/systemd/systemd-coredump），否则生成的不是原始 core 文件
• Go 程序若用了 syscall.SIGQUIT 或 os.Exit(0) 主动退出，不会产生 core；只有收到 SIGABRT/SIGSEGV 等未捕获信号才会 dump

为什么 gdb 显示的 goroutine ID 和 pprof 不一致？

gdb 里看到的 goroutine 17 是 runtime 内部的 mcache/g0 栈编号，不是 pprof 中的 goroutine ID（后者是 runtime.newG 分配的唯一递增序号）。两者无映射关系，别试图对齐。

立即学习“go语言免费学习笔记（深入）”；

• 想定位具体 goroutine 行为，优先看 runtime.gopark 的调用参数：第三个参数常是 reason 字符串，比如 "semacquire" 或 "chan receive"
• print *($sp + 32)（x86_64）有时能读到被 park 的 goroutine 的 g 结构体指针，但偏移随 Go 版本变，1.21 和 1.22 差异明显
• 真正可靠的现场还原方式是：用相同 Go 版本 + 同一构建参数重新编译，保留 .debug 段，再加载 core —— 其他都是妥协方案

实际调试中最容易卡住的，是以为 core 文件“自带上下文”，结果发现编译没开调试、ulimit 被截断、或者用错了 Go 版本的 runtime 符号。这些细节不补全，gdb 就只是个高级 hexdump 工具。