​PyTorch 训练随机卡死 Debug

一次真实的 debug 日志，记录我在图像检测训练中碰到的“训练进度条偶发停住但无报错”的玄学问题，最后定位到 DataLoader 的 fork 启动方式与 OpenCV 线程 的组合导致的死锁。下面是复盘出现的bug以及debug方法。

❓ Bug 现象

在本人进行python训练的适合，训练经常随机卡住（常见在第 1～3 个 epoch 或第 N 个 epoch 的第一批），无异常栈，GPU 利用率降为 0%，CPU 有 1～2 个 worker 核心 100% 占用。异常情况如下所示：

• 终端打印：DataLoader worker (pid XXX) is killed by signal: Bus error或者直接“静默卡死”，只有 CTRL+C 能打断。
• 将 num_workers 改为 0 后完全不再卡住，但吞吐骤降（训练速度惨不忍睹）。

排查步骤

1️⃣ 先把问题切半：是训练前向还是读取数据？

• 把模型前向全部注释掉，仅做 for _ in loader: pass，仍然卡住 → 问题在数据加载链路。
• 把 num_workers=0 后恢复 → 不再卡住，但吞吐下降 → 多进程读取链路存在并发问题。

2️⃣ 观察进程与系统状态

• htop/top：有 1～2 个 DataLoader worker 占 100% CPU。
• strace -p <worker_pid>：显示大量 futex(…, FUTEX_WAIT, …) 等待（线程锁等待）。
• 结论：很像是多线程库在 fork 后未重新初始化，典型嫌疑人是 OpenCV（它会使用 TBB/OMP/PThreads）。

3️⃣ 假设验证：fork + OpenCV 线程不安全

• 在 __getitem__ 最开头加 cv2.setNumThreads(0)：极大降低复现概率。
• 改 PyTorch 启动方法为 spawn（默认 Linux 是 fork）：彻底不再复现。
• 将 opencv-python 换为 opencv-python-headless（去掉 GUI/X11 依赖）：也更稳。

最终判断是由于Linux 下 DataLoader 使用 fork 复制主进程后，OpenCV 及其内部线程/加速库在子进程里存在初始化/锁状态不一致，导致偶发死锁。

解决方案

1️⃣ 方案 A：切换多进程启动方式为 spawn

• 代码放在 if __name__ == "__main__": 保护下 最早 执行。
• 注意：Jupyter/交互环境里不要随便 set（会报错），建议写到独立的训练脚本里。

2️⃣ 方案 B：更换 OpenCV 发行版并禁用其线程，用无 GUI 依赖的包，减少动态库冲突面：

pip uninstall -y opencv-python
pip install opencv-python-headless==4.8.1.78

import cv2
cv2.setNumThreads(0)

说明：OpenCV 内部经常会加载 TBB/OMP 等并行后端，与 PyTorch/DataLoader 的并发模型叠加后，fork 子进程可能拿到“复制但未重建”的线程状态，触发 futex 型等待。

3️⃣ 方案 C：DataLoader 参数与 Dataset 写法注意

• 打开 persistent_workers=True（PyTorch≥1.7），避免每个 epoch 频繁创建/销毁 worker。
• prefetch_factor 不宜过大（2–4 通常足够），否则 IO 争用放大。
• 不要在 Dataset 中“全局持有”非线程安全的对象（如长生命周期的 cv2.VideoCapture、PIL.ImageFont 等）；需要时在 __getitem__ 或 worker_init_fn 内部按需创建。
• 大图像集上尽量避免 cv2.imread + png 的极端混合；解码热点可以考虑 jpeg4py、turbojpeg、pyav、或者打包为 webdataset/tfrecord。
• Windows/Mac 下默认是 spawn，很少见到这个死锁，但建议也统一加 cv2.setNumThreads(0)。

以上就是本人遇到“玄学卡死”的完整复盘与修复。希望能帮你少踩一次 fork × 线程库 的坑。如果你也遇到 DataLoader 在 Linux 上偶发卡住、CPU 100%、GPU 掉空闲的情况，先换 spawn，再关 OpenCV 线程，十有八九能解决。