GDB不能自动检测内存越界，仅能定位崩溃位置；需配合ASan（-fsanitize=address）才能精准定位越界类型与位置，二者协同才是现代C++调试标准范式。
用GDB看崩溃现场，但别指望它直接报“越界”
GDB本身不检测内存越界，它只忠实反映程序崩溃那一刻的状态。当你看到SIGSEGV或SIGABRT，那只是结果——真正原因可能是堆/栈越界、释放后使用、野指针解引用等。GDB能帮你确认“哪里崩了”，但不能自动告诉你“为什么崩”。所以第一步永远是：先让程序在可调试状态下崩溃。
- 编译必须加
-g，否则backtrace看不到源码行号 - 避免用
-O2及以上优化，否则变量可能被优化掉、代码重排，step行为异常 - 若程序没崩而是静默出错（比如越界改写了相邻变量），GDB几乎无能为力——这时得换ASan
崩溃后用backtrace和info registers定位非法访问点
程序因段错误终止后，GDB会停在出错指令处。此时backtrace（或bt）显示调用栈，重点看最顶层帧：
- 如果最后一帧是
__asan_report_load_n或类似函数名，说明你已启用AddressSanitizer，GDB只是载体，真凶在ASan日志里 - 如果最后一帧是你的函数（如
function2），用frame 0切进去，再用list看上下文代码 - 用
info registers查$rdi/$rsi（x86-64）或$r0（ARM）等寄存器值，常能发现非法地址（如0x0、0xffffffffdeadbeef） - 用
x/10xw $rsp查看栈顶附近内存，验证是否因栈溢出破坏了返回地址
用watch和x手动追踪可疑内存变化
对疑似越界的数组或缓冲区，可在访问前设观察点，或直接读内存验证内容是否被意外覆盖：
-
watch *(int*)0x7fffffffe000：监听某地址的4字节整数被修改（需知道确切地址，可用p &arr[0]获得） -
x/5dw &arr[0]：以十进制显示arr起始连续5个int，检查是否有非预期值（比如本该是0,1,2,3,4，却出现0,1,2,-1,4，说明arr[3]被越界写入） -
print sizeof(arr)在函数内无效（传参退化为指针），得靠源码注释或info args确认传入的长度参数
别单独依赖GDB，搭配ASan才是C++越界排查的标准流程
纯GDB排查越界是逆向工程式操作，耗时且易漏。实际项目中应把ASan作为第一道防线：
立即学习“C++免费学习笔记（深入）”；
- 编译加
-fsanitize=address -g，运行时报错直接带出越界位置、访问类型（read/write）、分配/释放栈帧 - ASan报告里的
heap-buffer-overflow比GDB的SIGSEGV明确10倍 - GDB此时只用来加载ASan生成的core（
gdb ./a.out core），再用bt看ASan内部调用链，确认是否误报 - 注意：ASan与
valgrind不可共存，且不兼容某些自定义内存池——遇到误报先关ASan，回退到GDB+手工验证
越界问题最难的不是定位，而是复现条件和确认边界逻辑。GDB给你现场，ASan告诉你病因，两者缺一不可；但如果你还在用printf打点找越界，那已经落后两代调试范式了。
