1，训练功能问题定位思路
训练功能问题定位思路
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
