gdb加载core后变量不可见，主因是调试符号缺失或编译优化；需用带-g未strip版本复现，或加载debuginfo；定位变量须先frame切换栈帧，再info locals/print；优化导致变量消失时需降级编译复现。
gdb加载core后变量不可见？先确认符号是否完整
直接用 print 命令查不到变量值，大概率不是操作错，而是调试信息缺失。生产环境的可执行文件常被 strip 过，file your_program 输出里若含 stripped，说明符号表和调试信息已被移除——此时 info locals 为空、print var 报 No symbol "var" in current context 是正常现象。
必须用带 -g 编译的未 strip 版本（或对应 debuginfo 包）重新加载。临时补救：找同版本 rpm/deb 的 debuginfo 子包安装，或让运维提供 your_program.debug 文件，在 gdb 中用 symbol-file your_program.debug 手动加载。
bt看到崩溃点后，怎么定位并打印具体变量
崩溃时栈帧未必在你关心的函数里，bt 只是起点。关键步骤是先切到目标栈帧，再查变量：
-
frame 2（假设你想看第 3 层函数里的变量） -
info locals列出当前帧所有局部变量名及值（仅当有调试符号时有效） -
print my_struct.field_a访问结构体成员 -
print *ptr解引用指针（注意 ptr 本身是否为 NULL） -
print /x $rax查看寄存器值（十六进制），有时变量值就存在寄存器里没写回内存
若变量是全局或静态的，即使不在当前帧也能直接 print global_var，无需 frame 切换。
变量显示为 <optimized out></optimized> 怎么办
这是编译器优化（如 -O2）导致的典型现象：变量被分配到寄存器、复用或彻底消除。此时 print 和 info locals 都会显示 <optimized out></optimized>。
解决路径很窄：
- 唯一可靠办法是用未开启优化（
-O0）且带-g的版本复现 core —— 生产环境 core 无法绕过此限制 - 退而求其次：用
x/10xw $rbp-0x20手动查栈内存布局，结合源码偏移猜变量位置（需熟悉 ABI 和汇编） - 检查崩溃点附近是否有未优化的中间变量（如日志字符串字面量），它们可能残留地址线索
多线程下查变量容易漏掉关键线程
默认 bt 只显示当前线程（通常是崩溃线程），但问题根源可能在其他线程已破坏共享数据。必须主动切换：
-
info threads列出所有线程 ID 和状态 -
thread 3切到指定线程（ID 来自上一步输出） -
bt+info locals查该线程上下文 -
thread apply all bt一次性看全部线程调用栈（快速扫雷）
特别注意：某个线程卡在 pthread_mutex_lock 或 __lll_lock_wait，往往意味着死锁，此时它持有的变量状态比崩溃线程更关键——别只盯着 bt 最顶上那一行。
变量值不是总在内存里等着你 print；它可能被优化掉、藏在寄存器、跨线程污染，或者根本没符号可查。动手前先用 file 和 info files 确认二进制状态，比反复试 print 更省时间。
