gdb是定位c++程序崩溃问题的核心工具，通过gdb加载程序或core dump文件可快速分析段错误、内存越界等问题。首先确保开启core dump生成，使用ulimit -c unlimited并设置core_pattern路径；程序崩溃后用gdb ./your_program core加载core文件，执行bt查看调用栈定位崩溃点，结合frame、list、print var等命令查看上下文变量与源码。对于空指针或段错误，检查寄存器信息（info registers）和指针值（print ptr），确认非法访问地址。多线程场景下使用info threads和thread n切换线程，排查死锁或竞争条件。编译时应添加-g调试符号、关闭高阶优化（-o0）、启用-fno-omit-frame-pointer和-address-sanitize提升调试准确性。无法复现时可通过gcore pid生成内存镜像辅助分析。掌握这些技巧可高效定位大多数crash根源。
当C++程序在Linux环境下运行崩溃时，gdb是定位问题最有效的工具之一。掌握常用的gdb调试命令和Crash分析技巧，能快速定位段错误、内存越界、空指针、死锁等问题。
常用GDB调试命令
启动与加载程序
- gdb ./your_program：用gdb加载可执行文件
- gdb ./your_program core：用core dump文件调试崩溃现场
- gdb --pid=1234：附加到正在运行的进程（适合排查死循环或卡死）
运行控制
- run [args]：运行程序，可传入命令行参数
- continue (c)：继续执行被中断的程序
- step (s)：单步进入函数
- next (n)：单步跳过函数
- finish：执行完当前函数并返回
- kill：终止当前调试的程序
断点管理
立即学习“C++免费学习笔记（深入）”；
- break func_name：在函数处设断点
- break file.cpp:line：在指定文件某行设断点
- break *0x地址：在内存地址设断点（用于汇编调试）
- info breakpoints：查看所有断点
- delete [num]：删除某个或全部断点
- enable/disable [num]：启用/禁用断点
查看程序状态
- backtrace (bt)：打印调用栈，关键用于崩溃分析
- frame n：切换到第n层栈帧
- list：显示当前源码上下文
- print var：打印变量值，支持复杂表达式如print *ptr
- info locals：查看当前函数所有局部变量
- info registers：查看寄存器内容
- x/10x &var：以十六进制查看内存内容
Crash分析实用技巧
开启Core Dump生成
默认情况下系统可能不生成core文件。需执行：
ulimit -c unlimited并在程序目录确保有写权限。可通过echo '/tmp/core-%e-%p-%t' | sudo tee /proc/sys/kernel/core_pattern设置core文件路径格式。
使用Backtrace定位崩溃位置
程序崩溃后，运行bt查看调用栈。重点关注栈顶的函数，通常就是出错位置。若栈信息不完整，检查是否开启了编译优化（-O2以上）或未加-g调试符号。
结合编译选项提升调试效果
- 编译时加上-g：保留调试信息
- 关闭高阶优化：-O0，避免代码重排影响调试
- 启用地址消毒剂：-fsanitize=address，可自动发现内存越界、use-after-free等
- 使用-fno-omit-frame-pointer：便于更准确的栈回溯
分析空指针与段错误
崩溃后用bt定位到具体行，再用print ptr检查指针是否为0。结合info registers看崩溃时寄存器值，SIGSEGV通常对应非法内存访问。
多线程程序调试
- info threads：查看所有线程
- thread 2：切换到2号线程
- 在线程断点上使用break file.cpp:line thread all
- 注意死锁问题：多个线程互相等待资源，可用bt查看每个线程的阻塞位置
实战建议
遇到Crash先别急着改代码。保存core文件，用gdb加载后执行bt full查看完整调用栈和局部变量。若无法复现，考虑用ulimit -c unlimited配合日志记录运行环境。对于线上服务，可结合gcore pid手动导出内存镜像用于事后分析。
基本上就这些。熟练使用gdb命令，配合合理的编译和运行配置，大多数C++ Crash都能快速定位根源。
