调试assert时gdb/ddd为何在$HOME目录查找raise.c？

这事儿核心和调试符号表的路径记录以及系统调试包有没有装直接相关：

• 你触发的assert底层其实调用了libc库的raise()函数，raise.c就是实现这个函数的源码文件。当gdb要回溯到这里时，它会去读libc调试符号里记录的编译时raise.c的绝对路径。
• 如果你没装Ubuntu对应的libc调试包（比如libc6-dbg），gdb拿到的符号信息要么不全，要么里面记录的路径是libc编译时的临时构建目录（不是系统标准的源码路径）。这时候gdb会在默认搜索路径里瞎找，用户主目录就是它默认会扫的地方之一，所以就出现了在$HOME里找raise.c的情况。
• 还有一种可能：如果你之前在自己主目录编译过libc或者相关系统组件，gdb可能缓存了当时的源码路径，现在会优先去那里找。

给你几个实用的解决办法，按优先级来：

1. 先装系统调试包，一劳永逸
   先确认下你有没有装libc6-dbg，打开终端敲：

   dpkg -l | grep libc6-dbg
   

   如果没输出结果，就用这条命令安装：

   sudo apt update && sudo apt install libc6-dbg
   

   这个包会给libc补上完整的调试符号和正确的系统源码路径映射，之后gdb就能直接定位到/usr/src/glibc-xxx/下的raise.c，再也不会跑到你主目录瞎找了。

2. 直接让gdb放弃找系统库源码
   要是不想装调试包，也能让gdb跳过这个文件的查找。在ddd的gdb控制台里输入：

   set substitute-path /build/glibc-xxxx /dev/null
   

   这里的/build/glibc-xxxx是你从提示框里看到的gdb之前尝试找的路径，把它映射到/dev/null，gdb就会直接放弃查找，提示框自然就没了。

3. 清理gdb的路径缓存
   如果是之前在主目录编译过libc留下的缓存问题，删掉gdb的历史缓存文件就行：

   rm -f ~/.gdb_history ~/.gdbinit.d/*
   

   重启ddd之后，应该就不会再优先往你主目录跑了。

其实ddd只是gdb的图形界面壳子，所有源码查找的逻辑都是gdb在后台处理的。只要把gdb的路径问题搞定，ddd的提示框就消失了。另外，装调试包不光能解决这个小麻烦，还能让你看到系统库函数的具体实现，对深入调试代码帮助挺大的。

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