Debian下GDB分析Core Dump部分线程仅显__nanosleep_nocancel求助

这种情况我之前在Debian环境下排查过好几次，给你整理几个关键的排查方向：

• 检查线程在core dump生成时的状态
  线程2、3卡在__nanosleep_nocancel，说明它们当时正处于系统调用的内核睡眠阶段。内核生成core dump时，对于处于内核态的线程，可能不会完整保存用户态的栈帧上下文。你可以在GDB里切换到这些线程，执行info registers查看寄存器状态，尤其是rbp（帧指针）和rsp（栈指针），如果rbp的值异常，GDB就无法正确回溯栈。

• 确认调试符号的完整性与匹配性
  虽然线程5能展示完整栈，但线程2、3可能关联的动态库（比如libpthread）调试符号缺失或版本不匹配：

  1. 执行info sharedlibrary在GDB里查看所有加载的库，看哪些库标记为No debug symbols found；
  2. 在Debian上安装对应库的调试包，比如libpthread的调试包是libpthread-stubs0-dev-dbg（注意要和系统版本严格对应）；
  3. 如果调试符号不在默认路径，用set solib-search-path /path/to/debug/symbols告诉GDB去哪里找，或者用add-symbol-file手动加载符号文件。

• 排查编译器优化对栈帧的影响
  如果线程2、3对应的代码是用-O2及以上优化级别编译的，编译器可能会启用-fomit-frame-pointer选项，省略帧指针来优化性能，这会导致GDB无法自动回溯栈：

  1. 检查编译脚本里的优化选项，是否存在高优化级别；
  2. 在GDB里尝试用bt full替代bt，查看更多栈内存内容，手动分析可能的函数调用链；
  3. 如果可以重新编译代码，加上-fno-omit-frame-pointer选项保留帧指针，再重新生成core dump测试。

• 验证core dump的完整性
  内核生成的core dump可能因为资源限制或配置问题不完整：

  1. 检查ulimit -c的输出，确保core文件大小限制是unlimited；
  2. 查看Debian的coredump配置，比如/etc/systemd/coredump.conf里的Storage和MaxUse参数，确保有足够空间保存完整的core文件；
  3. 如果用coredumpctl管理core dump，执行coredumpctl info <pid>查看core文件的大小和生成状态，确认没有截断。

• 检查线程栈是否被破坏或换出
  极端情况下，线程栈可能因为溢出、内存损坏或者被内核换出到交换分区，导致core dump无法包含完整的栈数据：

  1. 在GDB里切换到线程2/3，执行x/100x $rsp查看栈内存内容，如果显示Cannot access memory at address ...，说明栈内存未被写入core dump；
  2. 检查内核参数vm.swappiness，如果值过高，可能导致栈页被换出，尝试临时调低后重新触发core dump测试。

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