pstack 在 Go 程序中常只输出主线程栈，因其底层依赖 GDB，而旧版 GDB 对 Go 运行时的 M:N 调度模型（含 sysmon、gc、idle worker 等系统线程）缺乏原生支持，导致 attach 失败或主动放弃遍历。

`pstack` 在 go 程序中常只输出主线程栈，因其底层依赖 gdb，而旧版 gdb 对 go 运行时的 m:n 调度模型（含 sysmon、gc、idle worker 等系统线程）缺乏原生支持，导致 attach 失败或主动放弃遍历。

Go 运行时在启动后会自动创建多个操作系统线程（OS threads），即使是最简程序（如仅调用 time.Sleep）也通常拥有 4–5 个线程：一个用户 goroutine 所在的 M（machine），加上 sysmon（系统监控）、gc（垃圾回收协程调度器）、idle worker 等后台线程。这些线程由 Go runtime 自主管理，不通过 POSIX pthread_create 显式暴露标准线程标识，也不完全遵循 GDB 期望的调试符号与栈帧约定。

pstack 的本质是一个 shell 封装脚本，其核心逻辑是调用 gdb 并执行 bt 或 thread apply all bt。它通过检测 /proc/<pid>/task/ 目录下线程数是否 >1 来决定是否启用多线程回溯。然而，关键问题在于：GDB 在尝试 ptrace(PTRACE_ATTACH) 到 Go runtime 创建的非 pthread 线程时，常因信号处理异常、寄存器上下文不匹配或缺少 DWARF 调试信息而失败。正如 strace 日志所示，GDB 对其余线程（如 LWP 5023/5024/5025）发出 PTRACE_ATTACH 后立即收到 SIGCHLD 并终止探查——这不是 pstack 的 bug，而是 GDB 与 Go 运行时底层机制不兼容的体现。

例如，以下三组手动 pstack 输出揭示了各系统线程的真实职责：

# sysmon 线程：负责监控调度器健康、抢占长时间运行的 goroutine
$ pstack 5094 | head -10
Thread 1 (process 5094):
#0  runtime.futex ()
#1  runtime.futexsleep ()
#2  runtime.notetsleep_internal ()
#3  runtime.sysmon ()   # ← 关键入口

# GC idle worker：等待 GC 唤醒，执行清扫或标记任务
$ pstack 5095 | head -10
Thread 1 (process 5095):
#0  runtime.futex ()
#1  runtime.futexsleep ()
#2  runtime.notesleep ()
#3  runtime.stopm ()
#4  runtime.findrunnable ()  # ← GC 调度循环

# netpoller 或定时器轮询线程（取决于 Go 版本）
$ pstack 5096 | head -10
Thread 1 (process 5096):
#0  runtime.futex ()
#1  runtime.futexsleep ()
#2  runtime.notesleep ()
#3  runtime.startlockedm ()
#4  runtime.schedule ()

⚠️ 注意：这些线程 ID（LWP）对应 /proc/<pid>/task/ 下的子目录，但 pstack 默认不会枚举并逐一调试它们。

根本解法并非修补 pstack，而是选用 Go 原生诊断工具：

• ✅ go tool pprof -goroutines <binary> <core>：获取 goroutine dump（含所有用户及系统 goroutine 状态）
• ✅ go tool pprof -threads <binary> <core>：查看 OS 线程映射关系
• ✅ kill -SIGQUIT <pid>：向进程发送信号，Go runtime 会将完整 goroutine 栈打印到 stderr（含 runtime.gopark、runtime.mcall 等关键帧）
• ✅ 升级至 GDB 8.0+：新版 GDB 增强了对 Go 线程模型的支持，配合 pstack 可正确输出 Thread 1 (LWP 18332), Thread 2 (LWP 18333) 等全部 LWP 回溯（需确保 Go 二进制含调试符号，编译时避免 -ldflags="-s -w"）

最后需明确：这不是 Go 的缺陷，而是调试工具链的历史适配问题。Go 选择轻量级、自包含的运行时设计，牺牲了部分传统调试器友好性，换取了极致的部署一致性与跨平台能力。当需要深度诊断并发行为时，应优先信任 go tool pprof 和 runtime/pprof，而非依赖通用 Linux 工具链强行解析 Go 的内部线程语义。