递归调试需用bt 10/-5限制栈帧、frame逐层检查状态、bt full暴露内存异常，并必须关闭编译器优化（-g -o0）以确保栈帧真实可信。
递归栈帧会自动累积，别指望bt只显示一层
递归函数每次调用都会压入新栈帧，GDB不会合并或折叠它们——这是理解递归调试的前提。如果你看到bt输出里一连串重复的函数名（比如全是reverse_list），不是GDB出错了，而是递归正在深入。栈顶（#0）永远是当前最内层调用，main所在的帧反而在底部（编号最大）。不加限制地执行bt，遇到深度为1000的递归，就会刷屏1000行，根本没法看。
实操建议：
- 用
bt 10限制只看最近10层，快速聚焦崩溃点附近 - 用
bt -5反向查看最外层的5帧（含main），确认递归入口是否符合预期 - 避免直接
bt——尤其没加-g编译时，符号缺失会导致帧信息混乱，先确认readelf -S your_binary | grep debug有输出
frame命令是递归调试的“显微镜”
递归问题的核心往往不在最后一层，而在某次中间调用的状态异常：比如指针为空、条件判断错位、返回值被意外覆盖。这时不能只盯着bt，必须用frame（缩写f）逐帧切入检查。
常见错误现象：递归反转链表时结果为空，但bt显示所有调用都“成功”返回了。实际是某一层的head->next被设成了NULL，而你没检查那一帧的局部变量。
实操建议：
- 用
f 2跳转到第3层（编号从0开始），再用info args和info locals确认输入参数和中间变量值 - 配合
up/down在相邻帧间移动，对比同一变量在不同深度的值变化（比如head指针如何一步步变NULL） - 若帧编号因优化错乱（如
bt里出现#0 0x... in ?? ()），改用frame *0x7fffffffd5a0按地址切换，地址可从bt输出中复制
bt full容易暴露递归逻辑漏洞
bt full不只是多打印几个变量——它强制GDB读取每个栈帧的完整寄存器和内存上下文。对递归函数来说，这能直接暴露“表面正常但底层已损坏”的状态。比如某次调用中head非空，但head->next指向了非法地址，bt只显示函数名，bt full却会把head->next = 0xdeadbeef这种关键线索打出来。
性能影响：深度递归下bt full可能卡顿数秒，因为GDB要逐帧解析调试信息并读内存；但比起盲目加日志重编译，这点等待值得。
实操建议：
- 崩溃后第一反应不是
bt，而是bt full 3——只展开最内层3帧，兼顾信息量和响应速度 - 如果
bt full报错Cannot access memory at address...，说明栈已被破坏，此时递归本身可能不是根源，要回头查更早的内存越界（比如前一个函数写了越界数组） - 注意
bt full显示的变量值是“该帧被中断时的快照”，不是函数返回后的最终值——递归返回过程中的修改不会体现在这里
递归调试必须关掉编译器优化
用gcc -O2编译递归代码，GDB看到的调用栈可能是假的：编译器会内联、尾调用优化、甚至把整个递归展开成循环。你断点打在reverse_list，实际执行的却是reverse_list.isra.12这类内部符号，bt输出里帧编号跳跃、参数消失、局部变量全<optimized out></optimized>。
这不是GDB的问题，是优化让源码和机器码脱节了。线上Release版本出问题？先用-g -O0复现，再调试。
实操建议：
- 编译时必须同时加
-g和-O0：gcc -g -O0 list.c -o list_debug - 验证是否生效：
gdb ./list_debug后执行info registers，若能看到rbp、rsp等寄存器值，且list能显示源码行，说明调试信息完整 - 别信IDE默认配置——CLion等工具可能默认启用
-O2，务必手动检查CMakeLists.txt或编译命令
head，其实它指向的数据刚被第2层的free()释放了。这时候frame 5里一切正常，frame 2里却藏着free(head->next)的痕迹——得靠bt -5倒着找，而不是顺着看。
