先切换到目标栈帧再查参数：用bt定位崩溃函数帧号，f N切换，info args查看实参；若无输出，需检查调试符号和优化级别；参数异常时应结合寄存器、内存及多线程上下文交叉验证。
崩溃时参数显示为空或乱码？先确认栈帧是否正确切换
直接运行 bt 只能看到调用链，但每个栈帧里的函数参数默认不自动打印。GDB 不会主动还原被优化掉的参数，尤其在 Release 编译下，info args 可能返回 “No arguments.” 或显示错误值。
必须先用 frame（或简写 f）跳转到目标栈帧——通常是崩溃点所在的那一层（比如 bt 输出里标着 #1 的那行），再查参数：
-
bt看完整调用栈，找到你想 inspect 的函数所在帧编号（如#1 process_data） -
f 1切换过去（编号从 0 开始，#0是最内层崩溃点） -
info args查当前帧的实参（注意：仅对未被编译器优化掉的参数有效）
为什么 info args 没输出？检查编译和调试信息是否完备
常见原因不是命令用错，而是构建环境缺失关键支持：
- 可执行文件没带调试符号：
file my_service应显示 “with debug_info”，否则info args基本失效 - 用了
-O2或更高优化级：GCC/Clang 会把参数存入寄存器甚至直接内联，info args无法还原；建议用-O0 -g重新编译用于调试的版本 - 函数是内联函数或被 tail-call 优化：此时该帧可能根本不存在，
bt里也看不到它，自然查不到参数
参数值异常？结合寄存器和内存手动验证
即使 info args 显示了值，也要保持怀疑——它可能已因栈破坏而失真。更可靠的方式是交叉验证：
- 用
info registers查看调用约定中传参寄存器（x86_64 是%rdi,%rsi,%rdx…；ARM64 是x0–x7），比对是否与info args一致 - 若参数是指针，用
x/s $rdi（x86_64）或x/s $x0（ARM64）看它指向的字符串内容；用x/10xw $rdi看前 10 个字（word）的内存布局 - 对结构体参数，
print *(struct my_s *)$rdi强制类型转换后展开，比依赖info args更直接
多线程环境下参数容易看错线程
core 文件只保存崩溃那一刻的线程状态，默认加载的是触发信号的那个线程（通常是 segfault 所在线程），但你要查的参数可能在另一个 worker 线程里。
- 先运行
info threads列出所有线程及其 GDB 内部 ID - 用
thread <id>切换到目标线程（不是 PID，是info threads左侧数字） - 再
bt→f N→info args，否则看到的可能是主线程的无关参数 - 特别注意：pthread_create 启动的线程如果传参是栈变量地址，崩溃时该栈早已销毁，此时
$rdi指向的内存大概率是垃圾数据
info args 不是“一键显示”，它只是调试链条上需要人工校验的一环。 
