catch load 比断点更早介入，能在动态库加载瞬间捕获，不依赖符号解析或源码，适用于多线程中由 dlopen 触发的隐式加载失败场景，且需按目标线程单独设置监听。
动态库加载失败时，catch load 比断点更早介入
当多线程程序因动态库未正确加载而崩溃（比如 undefined symbol 或 cannot open shared object file），常规断点往往来不及触发——因为出问题的代码可能根本没机会执行。此时 catch load 是唯一能“卡在加载瞬间”的手段。
它不依赖符号解析完成，也不要求源码可达，只要动态链接器调用 dlopen 或启动时自动加载，GDB 就能捕获。
-
catch load libxxx.so：只监听指定库名加载（注意不含路径，只匹配 basename） -
catch load：监听所有动态库加载，适合排查隐式依赖（如插件机制、RTLD_LAZY触发的延迟加载） - 加载失败时，GDB 仍会停住，但
bt显示的是_dl_open或__libc_dlopen_mode内部栈，需配合info sharedlibrary查看已加载项
多线程环境下，catch load 默认只对主线程生效
Linux 动态链接器本身是进程级的，但 catch load 的触发时机取决于哪个线程调用了 dlopen。如果子线程自行加载插件（常见于服务端模块热加载），主线程的 catch load 不会响应。
解决方法不是加全局监听，而是明确目标线程：
立即学习“C++免费学习笔记（深入）”；
- 先
run启动，等线程创建完毕后用info threads确认线程 ID - 用
thread <n></n>切到疑似加载库的线程（比如业务线程里调了dlopen） - 再在该线程上下文中执行
catch load（GDB 会绑定到当前线程） - 之后
continue，只有该线程触发加载时才会中断
漏掉这步，很容易误判为“库没加载”，其实是加载行为发生在你没监听的线程里。
info sharedlibrary 显示的路径可能被 RUNPATH 覆盖
调试时看到 info sharedlibrary 列出的路径和你预期不符？别急着改 LD_LIBRARY_PATH。现代链接器优先使用二进制中嵌入的 RUNPATH（或 RPATH），它比环境变量级别更高。
验证方式：
-
readelf -d ./your_program | grep -E 'RUNPATH|RPATH'查看嵌入路径 -
objdump -x ./your_program | grep PATH效果类似 - 若输出为空，才轮到
LD_LIBRARY_PATH和系统默认路径（/lib64,/usr/lib64） - 多线程程序中，不同线程加载同一库时，
info sharedlibrary只显示一次，但它实际由所有线程共享——这点容易误读为“只主线程加载了”
崩溃发生在动态库内时，bt full 常显示 ??，必须确认调试信息可用
多线程 + 动态库崩溃最典型的现象：bt 输出大量 ??，连函数名都看不到。这不是 GDB 失效，而是动态库编译时没带 -g 或被 strip 过。
关键检查点：
-
file /path/to/libxxx.so：输出含with debug_info才算有调试符号 -
nm -C /path/to/libxxx.so | grep your_func_name：确认符号未被删减 - 若用 CMake，确保
set(CMAKE_CXX_FLAGS_DEBUG "-g -O0")且未在 install 步骤执行strip - 多线程场景下，哪怕主程序有调试信息，只要崩溃点落在无调试信息的 so 里，
bt full就无法展开局部变量——这是最容易忽略的依赖盲区
真正棘手的不是“怎么断”，而是“断住了却看不懂栈”。动态库的调试信息缺失，在多线程中会被放大：你不知道是哪个线程在哪个库的哪行触发了问题，只能靠日志或 catch throw 配合交叉验证。
