info threads不显示参数，需切换线程后用info args或print查看；优化编译、符号缺失、系统调用阻塞会导致info args失效；c++对象参数应先验证地址有效性再裸内存查看；无真正一键脚本，推荐thread apply all bt筛选后单线程深入。
gdb里info threads只能看到线程ID和状态，看不到参数怎么办
默认情况下，info threads只列出线程编号、状态、函数名和栈顶地址，不显示任何参数。这是因为参数值在寄存器或栈上，且不同调用约定（如x86-64的%rdi %rsi %rdx %rcx %r8 %r9）存放位置不同，gdb不会自动解析并展示——它得知道当前帧的符号信息和调用约定才能还原。
真正能拿到参数值的入口是切换到每个线程的栈帧后，用info args或print显式查看：
- 先用
thread apply all bt快速扫一遍所有线程的调用栈，定位你关心的线程号（比如Thread 3） - 再用
thread 3切过去，然后frame 0确保在最顶层函数帧 - 执行
info args——如果调试信息完整（编译带-g），它会列出形参名和当前值；否则返回No arguments.
为什么thread apply all info args经常输出空或报错
这个命令看似省事，但实际成功率很低，原因很实在：
-
info args依赖调试符号中保存的参数类型和位置描述，而优化编译（-O2及以上）常把参数存入寄存器后复用，或内联函数，导致符号丢失 - 某些C++成员函数（尤其是模板实例或内联方法）的参数名在目标文件中根本没保留，
info args查不到符号就静默失败 - 若线程正阻塞在系统调用（如
pthread_cond_wait）或信号处理中，当前帧可能不是用户代码，info args自然无意义
更靠谱的做法是：对关键线程，手动thread N + bt确认是否停在你要看的函数，再info registers结合disassemble对照ABI查寄存器值（比如x86-64下第一个int参数大概率在%rdi）。
C++对象参数怎么打印，print直接崩或者显示不全
当参数是类对象（尤其含虚表、std::string、vector等）时，print可能卡住或只显示地址，常见原因有：
- 对象被移动或析构了一半（比如传的是右值引用，函数刚进入就
std::move了），内存已无效 - gdb加载了
libstdc++的Python pretty printer，但版本不匹配（如用gcc 12编译，gdb自带的是gcc 11的printer），导致print尝试调用不存在的_M_impl字段而报错 - 对象太大或含复杂嵌套（如
std::map），gdb默认递归深度为20，超出就截断——可临时设set print pretty on; set max-value-size 1000000
安全做法是：先print &arg_name确认地址有效，再用x/10gx &arg_name裸看内存布局，比强求print更可靠。
有没有一键脚本批量抓所有线程的指定函数参数
没有开箱即用的命令，但可以写个gdb命令序列应对固定场景。例如，你想查所有线程中正在执行process_request函数的const std::string&第一个参数：
thread apply all \
"thread; bt -n 5; if (\"process_request\" == *(char**)($rsp+8)) \
then print *(std::string*)($rdi); end"
注意这行只是示意：实际要根据函数签名、调用位置、ABI动态调整偏移（$rdi不一定总存第一个参数），且gdb的if条件不支持字符串比较，得靠python扩展。真要自动化，建议用gdb的python接口写个小脚本，遍历gdb.selected_inferior().threads()，逐个switch_thread后解析gdb.newest_frame().block()获取参数符号——但这已超出交互式调试范畴，更适合集成进CI日志分析流程。
日常够用的底线是：别信“一键”，老实用thread apply all bt筛出可疑线程，再单线程深挖。多线程调试里，最易被忽略的永远是——你看到的“当前值”，可能早被另一个线程改写了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
