栈溢出崩溃时GDB无法自动停在出错行，因栈结构被破坏导致bt截断、info frame异常、list找不到源码；关键判断依据是__stack_chk_fail、大量重复递归帧或Cannot access memory at address等现象。
栈溢出崩溃时GDB无法自动停在出错行？
不是GDB“不工作”，而是栈溢出本身破坏了调用栈结构，导致bt输出可能截断、info frame显示异常，甚至list找不到源码——因为返回地址被覆盖或栈指针$rsp已指向非法内存区域。
关键判断点：如果崩溃时看到__stack_chk_fail、Segmentation fault伴随大量递归帧（如stack_overflow at comp1.c:13反复出现），或gdb启动后直接报Cannot access memory at address 0x...，基本可锁定为栈溢出。
- 必须用
-fno-stack-protector编译才能复现原始栈溢出行为（否则__stack_chk_fail会提前终止） -
-O0必不可少：优化会内联或消除递归，掩盖真实栈增长路径 - 调试前先确认栈大小限制：
ulimit -s，默认通常为8MB；若程序需更大栈，得配合ulimit -s unlimited
用info registers和x/20xg $rsp看栈是否“掉下去”了
栈溢出的本质是$rsp持续减小，最终越界访问不可映射的低地址内存。GDB里最直接的证据就是寄存器和栈内存的异常值：
- 执行
info registers rsp rbp rip：若$rsp值远小于$rbp（比如差值超几MB），或$rsp落在0x7fff00000000以下（x86_64典型栈底边界），说明栈已穿底 - 执行
x/20xg $rsp：正常栈顶应有函数返回地址、保存的rbp等；若全为0x0000000000000000或重复的无效地址（如0x0000555555555149反复出现），大概率是递归写爆了栈空间 - 对比
info proc mappings输出：找[stack]段的起始地址，确认$rsp是否已低于该起始值
为什么bt只显示几层就断了？
bt依赖栈上保存的rbp链或return address推导调用关系。栈溢出时，这些元数据被新分配的局部变量（如char buffer[1024]）持续覆盖，导致GDB无法安全回溯。
- 不要依赖
bt full——它可能崩溃GDB自身 - 改用
frame 0后手动检查：x/10xg $rbp看当前帧的父rbp是否合理，x/gx ($rbp+8)读取返回地址再info symbol 0x...反查函数名 - 对递归函数，用
disassemble确认其入口是否有sub $0x400, %rsp这类大栈分配指令，这是溢出高危信号
core dump文件里怎么定位栈溢出起点？
生成的core文件本身不记录“第几次递归溢出”，但能暴露最后一次合法栈帧的痕迹：
- 用
gdb ./a.out core加载后，先info threads确认主线程（栈溢出几乎总发生在线程栈） - 执行
thread apply all bt：有时其他线程的栈更完整，能反推主线程溢出前的状态 - 重点看
frame 1或frame 2的局部变量：print buffer若报Cannot access memory，而print depth却有值，说明溢出就发生在该帧内 - 若
core中$rsp值为0x00007fffefff0000这类接近0x00007fff00000000的地址，基本可断定是栈底碰撞（stack collision）
真正难的不是识别栈溢出，而是区分它是纯逻辑错误（如无终止条件递归）还是资源配置问题（如ulimit -s太小）。前者改代码，后者调系统——GDB只能告诉你“栈没了”，但不会告诉你该加if (depth > 1000) return;还是该ulimit -s 16384。
