Gtest Text Fixture测试执行Remove后阻塞无输出问题排查

• 先抓调用栈定位阻塞点
  直接用gdb挂到卡住的进程上：

  # 先查进程ID
  ps aux | grep <你的测试程序名>
  # 挂到进程
  gdb -p <进程ID>
  # 查看所有线程的调用栈
  thread apply all bt
  

  看哪个线程停在哪个函数里——大概率是死锁、无限循环或者等待未触发的条件变量，这一步能直接缩小范围。

• 检查Remove方法的线程同步逻辑

  • 有没有嵌套加锁？比如Remove里先拿了A锁，又调用了需要B锁的方法，而其他线程是先拿B锁再拿A锁，直接死锁。
  • 锁的释放是否正确？比如有没有在return之前忘记解锁，或者异常路径下没释放锁（如果用的是裸锁而不是RAII锁比如std::lock_guard）。
  • 条件变量的使用是否规范？比如等待条件的时候是不是用while循环而不是if，有没有在修改条件后调用notify_one()/notify_all()？比如Remove操作触发了某个等待条件，但没通知，导致线程一直卡着等。

• 排查Remove里的容器操作逻辑

  • 有没有无限循环？比如遍历容器时，erase元素后没有正确更新迭代器，导致迭代器失效后进入死循环（比如for (auto it = container.begin(); it != container.end(); ++it)，erase后it会失效，直接++就会出问题）。
  • Remove操作是否涉及阻塞IO？比如意外调用了磁盘读写、网络请求这类慢操作，或者误操作了阻塞的队列/管道。

• 检查Gtest Fixture的生命周期

  • 测试用例之间的状态有没有残留？比如SetUp没有完全初始化容器，或者TearDown没有正确清理资源，导致Remove测试后，Fixture的清理逻辑卡住（比如等待某个线程退出，但线程因为Remove的问题没正常结束）。
  • 单独跑Remove测试用例，看是不是和其他测试的交互导致的阻塞：用--gtest_filter=MultiContainerTest.Remove*只跑Remove相关测试，排除其他测试的干扰。

• 验证容器的线程安全边界

  • 如果MultiContainer是线程安全的，有没有在Remove操作同时，其他测试线程还在访问容器？比如Fixture里的容器是成员变量，多个测试用例共享，导致Remove和其他操作并发冲突死锁。

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