gdb attach 是定位死循环最快手段：用 ps 找 PID，gdb -p PID 附加后 Ctrl+C 中断，bt 查栈顶函数与行号，list 看源码；无调试信息时用 info registers + objdump 定位汇编跳转。
gdb attach 进正在卡死的进程，直接看当前执行点
程序已经跑飞、CPU 占满但没崩溃时，gdb 是最快定位死循环位置的手段。不用重启、不用改代码，只要进程还在运行就能抓现场：
- 先用
ps aux | grep your_program找到 PID - 执行
gdb -p <PID>附加进去 - 输入
Ctrl+C中断运行（别输run） - 立刻执行
bt（即backtrace），看最顶层栈帧在哪一行、哪个函数里 - 再用
list查看那行附近的源码，基本就是死循环入口
注意：如果编译时没加 -g，bt 只能显示函数名和偏移，看不到行号；Release 模式下即使有 -g，也可能因优化导致行号错位——此时 info registers 看 rip（x86_64）或 pc（ARM），再结合 objdump -d your_program | grep <addr> 定位汇编跳转目标。
循环变量没更新？检查 while 条件里的变量生命周期和修改位置
90% 的手写死循环不是逻辑复杂，而是控制变量压根没变。常见于：
- 变量作用域错误：在
while外声明，但在内层if或子作用域里重新定义了同名变量（int i = 0;覆盖了外层i） - 漏写更新语句：比如
while (i 忘了 <code>i++ - 更新被跳过：
continue出现在更新语句之前，且条件分支未覆盖所有路径 - 浮点数比较陷阱：用
while (x != 1.0)控制迭代，因精度丢失永远不相等
解决方法不是“多打几个 cout”，而是把关键变量加 watch：gdb 里执行 watch i，再 continue，它会在 i 被修改时自动中断——如果一次都不中断，就坐实了“根本没更新”。
立即学习“C++免费学习笔记（深入）”；
Valgrind memcheck 对死循环无效，但能暴露背后的真实问题
valgrind --tool=memcheck 本身不会报“检测到死循环”，但它常在死循环触发前就暴露真正病因：
- 访问越界后修改了循环变量所在内存（比如数组越界踩坏了
i的值） - 未初始化变量用作循环条件（
int i;直接while (i ） - 释放后仍读写指针，导致条件判断逻辑错乱
所以当你怀疑是死循环，但 gdb bt 显示在某个看似正常的函数里反复跳转，优先跑一遍：valgrind --track-origins=yes ./your_program。它比单纯 memcheck 更容易揪出未初始化或非法内存操作引发的“伪死循环”。
std::this_thread::sleep_for 不能解决死循环，但能帮你确认是不是真卡死
加一句 std::this_thread::sleep_for(1ms) 到循环体末尾，看起来像“缓解卡顿”，实际是诊断开关：
- 如果加了之后 CPU 占用从 100% 掉到接近 0%，说明循环体本身不耗时，问题在外部阻塞（如
read()、accept()等系统调用没超时） - 如果 CPU 占用不变，才是纯计算型死循环
- 如果加了之后程序反而更快退出，大概率是竞态：另一个线程本该置位退出标志，但因调度延迟一直没生效，sleep 让出了时间片，恰好让标志更新被看到
这招不用于修复，只用于快速区分“忙等”和“假忙等”。真正修复得靠非阻塞 I/O、超时机制或 std::stop_token（C++20）这类协作式退出设计。
最易被忽略的一点：有些“死循环”根本不是循环写的有问题，而是信号处理没设对。比如 SIGINT（Ctrl+C）默认终止进程，但如果你用了 signal(SIGINT, SIG_IGN) 却忘了在循环里轮询 std::atomic_bool，那看起来就像按了 Ctrl+C 也没反应——其实程序早收到了信号，只是选择忽略并继续跑。
