gdb无法直接显示条件变量阻塞详情，需结合info threads、bt栈回溯、寄存器与内存查看（如x/20xg $rdi）定位cond地址及状态字段；唤醒失效多因时间错位，须检查锁保护、while循环守卫、signal前后锁操作；推荐用watch监控守卫变量而非cond本身，并配合scheduler-locking控制线程执行。
条件变量阻塞时，GDB看不到线程在等什么
因为 pthread_cond_wait 是系统调用级别的阻塞，线程实际停在 futex 等待上，GDB 默认只显示用户栈帧（比如停在 pthread_cond_wait 函数入口），但不会自动告诉你“它正在等哪个条件变量”或“哪个线程发了 signal”。你得手动查状态，否则容易误判为死锁。
- 先用
info threads确认哪些线程卡在pthread_cond_wait，注意看State列是否是blocked或waiting - 对目标线程执行
thread apply all bt，重点找带pthread_cond_wait的栈帧；如果栈顶是__futex_abstimed_wait_common或类似内核等待函数，基本可确认是条件变量挂起 - 用
frame切到pthread_cond_wait所在栈帧，再执行info registers和x/20xg $rdi（x86-64 下$rdi是第一个参数，即cond地址），可读出条件变量结构体前几个字段（如__g_signals、__wseq）来辅助判断信号是否已发出但未消费
为什么 pthread_cond_signal 似乎没唤醒线程
不是 signal 失效，而是常见三类时间错位：signal 发生在 wait 之前（唤醒丢失）、wait 时互斥锁没正确持有、或 signal 调用后锁未及时释放导致被唤醒线程无法抢到锁继续执行。GDB 本身不暴露这些逻辑竞态，必须结合代码上下文推理。
- 检查 signal 前是否已加锁：
pthread_mutex_lock必须在pthread_cond_signal之前，且 signal 后要尽快pthread_mutex_unlock - 检查 wait 是否在 while 循环里：
while (!condition) { pthread_cond_wait(&cond, &mutex); }—— 如果写成 if，就可能因虚假唤醒或唤醒丢失直接跳过重检 - 在 signal 所在线程断点处，用
p &cond记下条件变量地址；切到等待线程，用x/4xg &cond对比__g_signals字段变化（值 > 0 表示有未消费信号）
用 watch 监控条件变量关联的布尔状态更有效
直接打断点在 pthread_cond_wait 没用，它不暴露业务逻辑。真正该盯的是驱动 wait 的那个共享变量（比如 ready、data_available）。用硬件 watchpoint 抓住它被修改的瞬间，比猜“谁 signal 了”快得多。
- 启动调试前确保编译带
-g -O0，否则优化可能让变量被寄存器缓存，watch失效 - 在进入 wait 前设监控：
watch ready（假设条件变量守卫的是ready）；GDB 会自动转成硬件断点，命中时停在修改ready的那行代码 - 若提示
Could not insert hardware watchpoint，说明寄存器资源满，改用watch *(int*)&ready强制走内存访问路径，或换软件 watch：rwatch ready（只读触发，适合 signal 前赋值场景）
多线程下 continue 会让其他线程跑飞，怎么单步观察唤醒过程
continue 是全局恢复，所有线程一起动，你根本来不及看 signal 后 wait 线程如何抢锁、重检条件、退出循环。必须冻结无关线程，只放行关键路径。
- 用
thread <n></n>切到 signal 线程，执行set scheduler-locking on—— 这能让当前线程独占 CPU，其他线程暂停调度（注意：不是停止，是调度器不分配时间片） - 在 signal 前打条件断点：
b pthread_cond_signal if $rdi == (long)&my_cond（$rdi是条件变量地址参数），命中后手动step过 signal，再step过 unlock - 切到等待线程，用
set thread <m></m>+continue单独唤醒它，此时它会在 while 循环开头重新检查条件，你就能看到ready值是否已变
pthread_cond_wait 内部会原子地释放锁并挂起，但前提是调用前锁已被当前线程持有。GDB 看不到这个“原子性”，只能靠你人工核对 lock/unlock 的配对和顺序。
