1，训练功能问题定位思路

训练功能问题定位思路

Torch-npu错误码

CANN错误码

2，精度问题定位思路

3，未知错误定位技巧

3.1 通过 torch.npu.synchronize 定位

案例：训练网络过程中出现流同步报错，明显不是 python 报错行。

解决方案：使用 torch.npu.synchronize()排查报错位置。

第一步：首先增加环境变量：export TASK_QUEUE_ENABLE=0

第二步：在 77 行代码前每几行就加 torch.npu.synchronize()，再执行

有两种可能：

1、代码挂在新增的 torch.npu.synchronize()

2、代码没有挂在新增的 torch.npu.synchronize()

如果是第一种，则说明真实报错点在新增的 torch.npu.synchronize()之前

如果是第二种，则说明真实报错点在新增的 torch.npu.synchronize()之后

第三步：不停地打 torch.npu.synchronize()，直到找打这一行：它前面的 torch.npu.synchronize()没有报错，它后面的 torch.npu.synchronize()报错了。

第四步：构造 torch.gather 的单算子用例，成功复现报错：

3.2 通过 msprof 定位单算子问题

案例：训练网络过程中发现有算子报错，但不知道是哪个算子：

定位方案：使用 msprof 找到报错 api。

第一步：脚本内设置 callstack 开关和 e2e profiling，

第二步：运行脚本，msprof 数据会以 PROF_XXX 形式落盘到 profiler_result_path

第三步：解析 PROF_XXX 目录

第四步：将 timeline 目录中的 msprof.json 拖入 chrome://tracing/

第五步：从 profiling timeline 的末端观察报错的算子

第六步：torch.save 输入输出后进行单算子问题复现，提供 device 日志给研发确认（提交 issue、发帖）

第七步：研发确认，输入存在 inf

3.3 编译 debug 版本调试

案例：发生 coreDump 或者 Segment fault 后，使用 gdb 查看堆栈，存在“??”符号：

第一步：编译 debug 版本的包：DEBUG=1 bash ci/build.sh --python=3.8

编完 DEBUG，如果大小明显增加，如 9M 增加到 200+M，说明 DEBUG 选项生效；

第二步：执行 gdb python，进入 gdb，设置 break，比如我们要 debug GetDescForSerialization 函数，就输入 break GetDescForSerialization，选 y，也可以直接 break {文件}:{行数}。然后 run 脚本，例如此处我们的 python 脚本为 tmp.py，就输入 run tmp.py

第三步：gdb 会一路执行到 break 的点

相较于 release 模式，debug 模式下函数入参会显示为入参名字，可以直接 print 出来。我们打印下要 debug 的对象，如 p desc，可以看到 desc.base_sizes_的内部成员的变量没有初始化赋值，主要是由于 fake tensor 没有 storage 但走到了这个流程导致的，我们直接添加 storage 是否为空的判断即可通过用例。

3.4 更换 so 实现 debug 功能

案例：机器不支持编译 debug 版本，但是其他人有编译的 so。

解决方案：拷贝被人的 so，替换自己 torch-npu 安装目录下的 so

第一步：假如 torch_npu 安装目录为/root/miniforge-pypy3/envs/cbn/lib/python3.8/site-packages/torch_npu

打开 dbg 文件夹：

第二步：如果调用栈是 libtorch_npu.so 内的函数为问号，则将 libtorch_npu.so.debug 拷贝到/root/miniforge-pypy3/envs/cbn/lib/python3.8/site-packages/torch_npu/lib

注意：一定要保证 debug 文件和安装的 torch_npu 包是同一版本

3.5 python segment fault 定位到行的方法

解决方案：用 python -X faulthandler xx.py