断点位置不准90%源于符号缺失或源码/二进制不匹配：未加-g编译、高优化导致行号错乱、stripped二进制删符号、动态库未加载，或调试源码非编译版本；可用file和readelf验证调试信息存在性。
断点位置不准，90% 是符号信息缺失或源码/二进制不匹配导致的，不是 GDB 本身出错。
为什么 break main 会停在错误行甚至报 pending？
这通常意味着 GDB 找不到 main 的调试符号，或者该函数位于尚未加载的共享库中。常见原因包括：
- 编译时没加
-g，导致没有 DWARF 调试信息，GDB 只能靠地址硬猜行号 - 用了
-O2或更高优化等级，函数内联、代码重排后，源码行号和机器指令不再一一对应 - 你调试的是 stripped 版本（比如线上部署包），
strip已删掉所有符号和调试段 - 断点设在动态链接库（如
libxxx.so）里，但该库还没被dlopen加载，GDB 提示Make breakpoint pending on future shared library load?
验证方法：运行 file ./your_program，输出里若不含 with debug_info，基本可确认无调试符号；用 readelf -S ./your_program | grep debug 查看是否有 .debug_* 段。
break file.c:15 停在第 18 行怎么办？
这是典型的源码与二进制不一致——你当前打开的 file.c 不是编译时用的那个版本。GDB 依赖编译时嵌入的绝对路径定位源码，一旦路径变了或文件被改写，行号映射就失效。
- 用
info sources查看 GDB 实际加载的源文件路径，确认是否指向你预期的副本 - 用
list命令直接看 GDB 当前认为的“第 15 行”长什么样，往往能立刻发现内容对不上 - 如果项目用 CMake / Make，检查是否启用了
-frecord-gcc-switches或set(CMAKE_CXX_FLAGS_DEBUG "-g -O0")，确保 debug 构建禁用优化 - 避免在构建目录外编辑源码后重新编译——改完代码务必重新
make，不要只改源码不重编
多线程下断点跳转到奇怪位置？注意线程调度干扰
这不是断点“不准”，而是你正在调试的线程被抢占或切换了。例如你在主线程设了 break thread_proc，但实际触发时可能已切换到 worker 线程上下文，list 显示的代码看起来“不属于当前函数”。
- 用
info threads确认当前活跃线程 ID，再用thread N切回目标线程再list - 用
bt（backtrace）看当前栈帧，确认断点是否真落在你想停的位置，还是被信号/系统调用打断了 - 若需稳定复现，可在断点命令后加
silent; bt; continue自动打印栈再继续，避免手动切线程遗漏
最常被忽略的一点：GDB 不会校验你本地源码是否和编译产物同步。它只相信二进制里记录的路径和行号。哪怕你改了一行注释并保存，只要没重新编译，GDB 就永远按旧快照解析——这个“不准”其实是你自己的环境没对齐。
