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 —— 其他都是妥协方案
