因为gdb默认只停在主线程，定时器线程可能已退出、阻塞在nanosleep等系统调用中，或未启用-pthread编译导致无法识别；需用info threads查所有线程，thread <n>切换后bt，并确保回调函数可寻址、未内联、带调试符号。
gdb 调试时为什么看不到定时器线程的堆栈？
因为 std::chrono + std::thread 构建的定时器（比如用 std::this_thread::sleep_for 循环等待）通常运行在独立线程中，而默认 gdb 只停在主线程，其他线程可能已退出、被调度走，或正阻塞在系统调用里（如 nanosleep），导致 bt 看不到有效帧。
- 确认所有线程是否启用调试：启动时加
-pthread编译，否则gdb无法识别线程状态 - 运行中用
info threads查看线程列表，注意带sleep或futex的线程——那很可能是你的定时器线程 - 用
thread <n>切换到对应线程号后再bt，别只在主线程里找 - 如果线程状态是
Blocked或Waiting，说明它还没执行到你设的断点位置，得提前在定时器回调函数入口下断
如何在定时器回调函数里稳定打断点？
直接对 lambda 或临时函数对象下断点几乎无效——它们没有符号名。必须让回调可寻址：
- 把定时器逻辑封装进命名函数，例如
void on_timer_tick() { ... }，然后在线程里调用它 - 若用
std::async或std::thread启动，确保该函数未被内联：加__attribute__((noinline))（GCC/Clang）或[[gnu::noinline]] - 编译时禁用优化：
-O0，否则gdb可能找不到变量、跳过断点，甚至把整个循环优化掉 - 断点命令建议用
break on_timer_tick而非行号，避免因代码微调导致断点失效
定时器触发后程序行为异常，怎么确认是竞态还是信号干扰？
Linux 下基于 timer_create(CLOCK_MONOTONIC, ...) 或 setitimer 的定时器会发 SIGALRM，而 C++ 多线程程序默认不处理信号，容易导致任意线程被中断、破坏锁状态。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 检查是否用了
signal()或sigaction()：若没显式屏蔽，SIGALRM可能落在持有std::mutex的线程上，引发死锁或std::terminate - 用
handle SIGALRM stop nopass让gdb捕获信号并暂停，再查info registers和bt确认中断点 - 更安全的做法是避免基于信号的定时器，改用
std::condition_variable+wait_until，这样完全在用户态可控 - 如果必须用信号，在主线程调用
pthread_sigmask(SIG_BLOCK, &set, nullptr)屏蔽SIGALRM，再指定一个专用线程用sigwait处理
为什么 step 进入 std::this_thread::sleep_for 就卡住？
这不是卡住，是 gdb 在单步进入系统调用（如 clock_nanosleep）后，必须等超时返回才能继续——你没法“单步”过一个睡眠。
立即学习“C++免费学习笔记（深入）”；
- 别对
sleep_for本身下step，应在它之前设断点（比如定时器循环的开头），再用continue让它自然唤醒 - 想观察唤醒后的行为，就在
sleep_for下一行立即设断点，而不是试图单步进去 - 若需精确控制唤醒时机，可在代码中用
std::atomic_bool配合cv.wait_until，这样gdb可以在条件变量上设条件断点：break on_timer_tick if !ready.load()
std::thread 默认栈），一旦回调里局部变量过大或递归调用，可能静默栈溢出，gdb 显示的堆栈就是乱码或截断——这时得用 info proc mappings 查线程栈地址范围，再配合 x/20xg $rsp 手动 inspect。 
