为何GDB中futex断点与write()会相互影响导致程序异常？

先修正代码中的致命错误 #

你代码里有个拼写错误：mux.lock()应该是mtx.lock()——你定义的互斥量是std::mutex mtx;，mux是未声明的标识符，这会导致编译失败，应该是输入时的笔误。

核心问题分析 #

当你用catch system futex全局拦截所有futex系统调用时，会触发大量断点，而这和std::cout的底层实现直接冲突：

• std::cout本身是线程安全的，但其底层输出操作会用到内部互斥锁，这个锁同样依赖futex系统调用。
• 当某个线程执行cout时，会先获取内部锁（触发futex调用），然后进入write()系统调用输出内容。此时如果GDB因为其他线程的futex调用触发断点，会暂停整个进程的执行，导致卡在write()的线程无法完成输出、释放内部锁。
• 其他线程此时都在等待cout的内部锁（不断触发futex调用），GDB会不断在这些线程的futex断点上暂停，形成你看到的“无限循环”——每次按c继续，GDB立刻停在另一个线程的futex调用上，永远轮不到卡在write()的线程继续执行。

当你注释掉所有输出代码后，没有了cout内部锁的futex调用，只有你自己定义的mtx相关的futex操作，断点触发频率大幅降低，程序就能正常运行。

解决办法 #

1. 缩小futex监控范围：不要全局拦截所有futex调用，而是只监控和你自己的互斥量mtx相关的futex。可以通过获取mtx的底层futex地址，设置条件断点：

   # 先获取mtx的底层锁地址（以glibc为例）
   p &((std::mutex*)&mtx)->__data.__lock
   # 假设输出是0x12345678，设置条件断点
   catch system futex if $rdi == 0x12345678
   

2. 控制GDB线程调度：在调试时开启线程锁定，避免断点切换线程：

   set scheduler-locking on
   

   这样当GDB停在某个线程的断点时，其他线程不会运行，你可以手动切换到卡在write()的线程，按c让它完成输出。
3. 临时替换输出方式：调试期间用不依赖内部锁的输出（比如直接调用write(1, ...)，但要注意线程安全），或者暂时注释输出代码，调试完成后再恢复。

内容的提问来源于stack exchange，提问作者deadpool