崩溃后第一眼应看bt输出的栈顶帧#0，它直接指出程序挂掉的具体指令、代码行和函数，多数段错误、空指针解引用等均发生于此；若bt深度大且顶层在malloc/free/pthread_mutex_lock内，优先怀疑堆损坏或锁异常；栈帧不全则可能是编译时启用了-fomit-frame-pointer优化所致。
崩溃后第一眼先看 bt 输出的栈顶帧
不是先查线程列表，也不是急着切线程——bt（backtrace）显示的最顶层帧（#0）直接告诉你程序在哪条指令、哪行代码、哪个函数里挂掉的。多数段错误、空指针解引用、非法内存访问都停在这里。
常见陷阱是看到多线程就默认“问题在线程切换”，结果 bt 显示崩溃发生在主线程的 main 里调用 pthread_create 失败后没检查返回值，直接用了未初始化的 tid 变量——这根本不是多线程并发问题，而是单线程逻辑错误。
-
bt如果只有一两层（比如 #0 在__GI_raise、#1 在__GI_abort），说明是主动 abort，要结合info registers看%rdi或%rsi是否存了错误码，再查man 3 abort - 如果
bt深度很大（>10 层），且顶层在malloc、free或pthread_mutex_lock内部，优先怀疑堆损坏或锁状态异常，而不是业务逻辑 - 若
bt显示顶层在系统调用（如clone、futex），说明线程可能卡在等待态，此时才需要转向info threads和thread apply all bt
info threads 要结合线程状态字段一起读
info threads 列出的不只是 ID 和名字，每行末尾的 running、sleeping、blocked、idle 才是关键信号。不要只扫 ID 数量。
例如输出中出现：3 Thread 0x7ffff77c2700 (LWP 1234) 0x00007ffff7b8a387 in __GI___pthread_timedjoin_ex (threadid=140737349965568, thread_return=0x0, abstime=0x0, block=<optimized out>) at pthread_join_common.c:80</optimized>
这行末尾没有状态标记，实际是 blocked（卡在 pthread_join），但 GDB 默认不显式标出——得靠你识别函数名和地址是否停在同步原语内部。
- 看到多个线程都停在
pthread_mutex_lock、pthread_cond_wait或futex，立刻怀疑死锁或条件变量未唤醒 - 一个线程显示
running，其余全是sleeping或无状态，说明可能只有它在干活，其他线程被意外阻塞或已退出 - 所有线程都显示
idle且bt停在nanosleep或poll，程序可能只是正常休眠，不是崩溃
崩溃点在线程创建/销毁阶段，pthread_create 和 pthread_join 参数必须人工核对
很多多线程崩溃其实发生在“线程生命周期管理”环节，而非业务执行中。GDB 不会自动提醒你传了野指针给 pthread_create，也不会指出 pthread_join 的 tid 已被复用或未初始化。
典型错误示例：
— pthread_create(&tid, NULL, func, &local_var)：&local_var 是栈变量地址，线程还没启动，主线程函数已返回，地址失效
— pthread_join(tid, NULL) 前没检查 pthread_create 返回值，tid 是垃圾值
— 同一个 tid 被 pthread_join 两次，第二次触发 undefined behavior
- 用
print tid确认线程 ID 是非零有效值（Linux 下合法pthread_t通常非零） - 用
info proc mappings查&local_var地址是否落在栈段（[stack]）内，若是，基本可判定悬垂指针 - 崩溃若发生在
pthread_exit或线程函数 return 后，检查是否忘了pthread_detach或重复join
core 文件里线程栈被截断？优先检查编译时是否用了 -fomit-frame-pointer
当你用 gdb ./a.out core.xxx 加载 core 后，bt 显示栈帧不全（比如只有 #0，或者中间缺帧），不是 GDB 坏了，大概率是编译器优化抹掉了帧指针。
尤其在 Release 编译中，GCC/Clang 默认开启 -fomit-frame-pointer，导致 GDB 无法可靠回溯栈。这不是多线程特有，但多线程下影响更大——你可能误判某线程“没栈”，其实是栈信息丢了。
- 验证方式：
readelf -S ./a.out | grep debug确认有调试段；再运行objdump -d ./a.out | grep -A5 "<function_name>"</function_name>，看函数入口是否有push %rbp; mov %rsp,%rbp - 修复方法：编译时加
-fno-omit-frame-pointer（即使开了-O2也建议加上） - 临时补救：在 GDB 中用
set backtrace past-main on和set backtrace limit 100尝试强制展开，但不可靠
真正难啃的多线程崩溃，往往藏在“看起来正常的调用链”里——比如 bt 显示一切停在 pthread_mutex_lock，但锁本身没问题，问题出在上层业务逻辑提前释放了锁保护的资源。这时候得顺着 bt 往回推，一帧一帧看变量值，而不是盯着线程数或锁名打转。
