如何调试会触发gdb内部错误的C++程序？

方案1：优先尝试修复GDB兼容问题（成本最低） #

• 升级GDB到最新稳定版：你遇到的是GDB 10.1处理DWARF调试信息的已知内部错误，多由旧版本GDB不兼容DWARF 5、split dwarf、-g3等新编译选项导致，升级到13.x/14.x版本的GDB，90%以上的场景可以直接解决该断言报错，不需要调整其他流程。
• 降级调试信息格式：不想升级GDB的话，编译项目时加上-gdwarf-4参数，强制生成GDB 10.1支持的DWARF 4格式调试信息，也可以绕开该读取错误。

方案2：使用替代调试工具 #

• lldb：LLVM生态的调试器，和GDB命令语法重合度很高，常用的run、bt、break等命令完全一致，对DWARF调试信息的兼容性优于旧版GDB，直接执行lldb 你的可执行文件路径即可启动调试，适配成本极低。
• valgrind：用memcheck工具运行程序，执行valgrind ./你的可执行文件，启动崩溃时会直接输出精确的错误类型（空指针访问/越界/非法内存访问等）、完整调用栈、触发问题的代码位置，不需要手动打断点，适配启动即崩溃的场景非常方便。
• rr：可逆调试工具，先执行rr record ./你的可执行文件记录运行轨迹，崩溃后执行rr replay即可复现崩溃现场，支持正向/反向执行调试，比原生GDB排查问题效率更高。

方案3：无需调试器的段错误捕获方案 #

• 生成core dump离线分析：先执行ulimit -c unlimited打开核心转储限制，运行程序崩溃后会生成core文件，可直接用高版本GDB、objdump、readelf等工具离线分析core文件，不需要运行程序时挂载调试器，绕开GDB运行时的内部错误。
• 代码内置栈回溯打印：在程序入口注册SIGSEGV信号处理函数，调用glibc提供的backtrace()、backtrace_symbols()函数打印调用栈，编译时加上-rdynamic参数，崩溃时会直接输出完整的函数调用链到标准输出或日志中，不需要调试器即可定位崩溃位置。
• 动态链接过程调试：如果崩溃发生在动态库加载/初始化阶段，执行LD_DEBUG=all ./你的可执行文件 2>&1 | head -1000，可以输出完整的动态库查找、重定位、初始化执行过程，直接定位到崩溃发生的链接阶段步骤。

方案4：快速定位的笨办法 #

启动即崩溃的问题多和全局对象构造、动态库初始化逻辑相关，可通过二分注释最近改动的代码、替换依赖的链接库版本的方式，快速缩小问题范围，定位到触发崩溃的模块。

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