启用faulthandler是最快定位PyTorch段错误位置的方法，它强制Python崩溃时打印C层调用栈；需在import torch前启用，重点排查扩展模块加载环节的.so文件兼容性问题。
直接启用 faulthandler 是最快定位 PyTorch 段错误位置的方法，它能强制 Python 在崩溃时打印出 C 层调用栈，而不是静默退出。
为什么 import torch 就崩？先看是不是环境冲突
很多段错误在 import torch 阶段就触发，根本跑不到你的模型代码。这不是你写的逻辑问题，而是底层 C 扩展加载失败或被污染：
- 第三方库（如
torch_geometric、torch_sparse）和当前 PyTorch 版本不兼容，它们的 C 扩展可能覆盖了 PyTorch 内部符号 - 多个 conda/pip 环境混用，导致
.so文件路径错乱，Python 加载了旧版或 ABI 不匹配的二进制模块 - 显卡驱动与 CUDA/ROCm 运行时版本不匹配，尤其在 AMD GPU（如 RX 7600 XT）或较新 NVIDIA 架构上常见
-
TORCH_COMPILE_DEBUG=1+CUDA_LAUNCH_BLOCKING=0组合会放大静态图编译器（inductor）中的内存访问缺陷，引发 SIGSEGV
怎么让崩溃“说话”：用 faulthandler 打印真实堆栈
PyTorch 段错误常发生在 C/C++ 层，Python traceback 默认不显示。必须靠 faulthandler 把底层调用链拽出来：
- 命令行启动时加参数：
python -X faulthandler your_script.py - 如果脚本已封装成入口（如
train.py），在文件最顶部import后立刻加：faulthandler.enable() - 关键点：必须在
import torch之前启用，否则加载失败时faulthandler自身都来不及注册 - 输出中重点看
line XXX in .../__init__.py或ctypes/__init__.py这类路径——说明崩溃发生在扩展模块加载环节，不是你训练逻辑的问题
排查 torch._C._jit_pass_fold_conv_bn 类型的崩溃
这类堆栈出现在启用 torch.compile(backend="inductor") 后，往往指向 PyTorch 3.0 静态图编译器的内部 pass。它不是你代码写错了，而是编译器在优化过程中触发了未处理的内存边界条件：
- 临时关闭编译：
compiled_model = model替换掉torch.compile(...)，确认是否恢复稳定 - 降级编译强度：
mode="default"替代"max-autotune"，避免某些 aggressive 的 fusion 导致内存越界 - 检查 NCCL 和 CUDA 上下文状态：这类崩溃常伴随
cudaErrorLaunchFailure，需确认dist.init_process_group后没有跨进程共享未同步的 tensor 引用 - 不要依赖
torch.cuda.synchronize()捕获异步错误——它不会阻止段错误发生，只是让崩溃延迟几毫秒
真正棘手的是那些只在多进程 DataLoader 或 Ape-X 分布式训练中复现的段错误：它们往往源于子进程 fork 后对 CUDA 上下文、文件句柄或第三方 C 库全局状态的非线程安全访问。这种问题无法单靠日志定位，必须结合 gdb python -ex "r" --args python -X faulthandler ... 抓住 core dump 文件分析内存映射。但绝大多数情况，先用 faulthandler 锁定到具体 .so 文件名，再核对版本兼容性，就能解决八成问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
