Torch-npu报错定位技巧

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

本文由博客一文多发平台 OpenWrite 发布！