CANN Runtime错误排查完全指南错误码解读、异步错误定位与plog日志分析【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtimeCANN Runtime 是华为 CANN 软件栈中负责 Ascend NPU 运行时核心实现与维测功能的组件。本文面向新手带你一次搞懂CANN Runtime 错误排查的完整方法论如何快速解读错误码、如何定位延迟暴露的异步错误、以及如何通过plog 日志分析锁定 Device 侧异常根源。 先搞懂CANN Runtime 的错误从哪里来CANN Runtime 的错误本质上分两类排查思路完全不同错误类型发生位置表现方式排查入口同步错误Host 侧API 直接返回非 0 错误码检查 API 返回值 错误码表异步错误Device 侧API 返回成功任务稍后才失败同步接口 错误查询接口 plog 日志理解这一点非常关键调用aclrtMemcpyAsync等异步接口返回成功只代表任务下发成功不代表 Device 上真的执行成功了。这是新手最容易踩的坑。CANN 中存在两套错误码体系数值型返回码aclError类型如107000参数非法、107001Device ID 无效定义在 rt_error_codes.h 中6位字符错误码形如EE1023第一位表示级别E 错误 / W 告警 / I 提示第二位表示模块后四位是错误编号。这类错误码在 docs/zh/error_code_ref/ 目录下有逐条解读。 错误码速查三类高频错误码解读遇到报错别慌先按前缀分类再查对应文档EE1xxx/EE4xxx/WE0xxx—— RuntimeRTS错误如参数非法、模型绑定失败、上下文无效等完整清单见 RTS-Errors.mdEH0xxx—— ACL 层错误绝大多数是参数非法或空指针见 ACL-Errors.mdEE1023资源不足—— Device 上 Stream / Event / Notify 等硬件调度资源耗尽的高频问题可先读 EE1023资源不足问题.md 中的 retCode 对照表。几个高频场景的快速入口现象大概率原因参考文档aclInit失败驱动/固件版本不匹配、设备未启动aclInit初始化失败常见原因排查.mdaclrtMalloc失败显存不足、内存碎片、地址空间限制aclrtMalloc内存申请失败常见原因.md算子输出全 0内存未初始化、数据类型不匹配、拷贝失败算子执行输出全0的常见原因排查.md⏱️ 异步错误定位接口返回成功任务却失败了这是 CANN Runtime 错误排查中最典型的问题详见 如何获取和解读Runtime异步错误码.md。掌握下面 4 个方法基本可以覆盖所有场景方法 1下发后立即同步—— 在异步任务后立即调用同步接口当场拿到真实执行结果aclrtMemcpyAsync(devPtr, devSize, hostPtr, hostSize, ACL_MEMCPY_HOST_TO_DEVICE, stream); // 立即同步暴露 Device 侧的真实错误 aclError error aclrtSynchronizeStream(stream); if (error ! ACL_RT_SUCCESS) { printf(Async task failed: %d, msg: %s\n, error, aclGetRecentErrMsg()); }方法 2用错误查询接口兜底——aclrtPeekAtLastError查看但不重置和aclrtGetLastError获取并重置可查询当前线程累积的 Runtime 错误。方法 3aclGetRecentErrMsg()拿人类可读的错误描述—— 配合错误码一起打印诊断信息立刻完整。方法 4开启遇错即停模式—— 用aclrtSetStreamFailureMode(stream, ACL_STOP_ON_FAILURE)让首个错误发生时就停止执行避免后续任务覆盖现场。若 Stream 上任务很多难以定位可参考 遇错即停模式下错误定位方法.md 中的分段同步 Event 标记任务边界技巧。 官方提供了一个错误处理基础样例演示了如何统一检查 ACL 返回值并组合使用上述诊断接口example/0_quickstart/1_error_handling/main.cpp。 plog日志分析四步锁定 Device 侧异常当错误码只是告诉你出错了而 plog 日志会告诉你错在哪、为什么错。plog 是 Host 侧应用类日志默认路径为$HOME/ascend/log/[run|debug]/plog/plog-pid_*.log日志格式为[Level] ModuleName(PID,PName):DateTimeMS [FileName:LineNumber] LogContent格式详解见 log_overview.md。完整方法见 如何通过plog日志定位Device侧异常.md核心是四个 grepgrep Task run failed plog.log # ① 定位失败任务device_id / stream_id / task_id grep fault kernel_name plog.log # ② 定位失败内核fault kernel_nameAdd_xxx grep retCode plog.log # ③ 分析错误码如 retCode0x31 [vector core exception] grep The error from device plog.log # ④ 查看芯片/Die/核心级异常详情一条典型日志的解读示例[ERROR] RUNTIME(2082291,python3):2024-07-04-14:14:25.050.365 [davinic_kernel_task.cc:1219] PreCheckTaskErr: Kernel task happen error, retCode0x31, [vector core exception]. fault kernel_nameAdd_ee98c6628030785f610b924ab1557b31_high_performance_210000000解读要点retCode0x31表示AI 向量核aivec异常常见于数组越界或 tiling 参数计算错误fault kernel_name直接点名了出错的算子内核后缀中的210000000是 tiling key可用于反查算子实现。常见日志特征对照表日志特征异常类型排查方向retCode0x31, [vector core exception]向量核异常数组越界、内存分配不足、tiling 计算错误errType0x2 (task timeout)任务超时死循环、计算量过大、硬件资源不足retCode0x7020023Alloc Stream failedStream 资源不足减少并发 Stream / 检查资源泄漏retCode0x7110019async copy tasks 达上限异步拷贝队列满减小numBatches等批量参数如果默认日志信息不够可通过环境变量提升详细度export ASCEND_GLOBAL_LOG_LEVEL0DEBUG 级并可用ASCEND_LOG_PRINT_TO_STDOUT1让日志直接输出到终端。✅ 一套完整的排查清单收藏备用看返回值每个 ACL API 调用后检查aclError是否等于ACL_RT_SUCCESS立即同步异步任务后用aclrtSynchronizeStream/aclrtSynchronizeDevice暴露真实错误查错误描述aclGetRecentErrMsg()打印人类可读信息对照 error_code_ref 目录定位含义开遇错即停调试期用ACL_STOP_ON_FAILURE保住现场生产环境再权衡grep plog按任务 → 内核 → retCode → 设备详情四步深挖 Device 侧异常提升日志级别信息不足时切换 DEBUG 级别重跑一次。掌握这套流程从莫名失败到精确定位通常只需要 10 分钟。更多场景可继续参考 docs/zh/FAQ/ 下的 Stream 同步、多 Device 跨设备下发等专题以及 api_ref/13_exception_handling.md 中的官方异常处理 API 说明。【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CANN Runtime错误排查完全指南：错误码解读、异步错误定位与plog日志分析
CANN Runtime错误排查完全指南错误码解读、异步错误定位与plog日志分析【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtimeCANN Runtime 是华为 CANN 软件栈中负责 Ascend NPU 运行时核心实现与维测功能的组件。本文面向新手带你一次搞懂CANN Runtime 错误排查的完整方法论如何快速解读错误码、如何定位延迟暴露的异步错误、以及如何通过plog 日志分析锁定 Device 侧异常根源。 先搞懂CANN Runtime 的错误从哪里来CANN Runtime 的错误本质上分两类排查思路完全不同错误类型发生位置表现方式排查入口同步错误Host 侧API 直接返回非 0 错误码检查 API 返回值 错误码表异步错误Device 侧API 返回成功任务稍后才失败同步接口 错误查询接口 plog 日志理解这一点非常关键调用aclrtMemcpyAsync等异步接口返回成功只代表任务下发成功不代表 Device 上真的执行成功了。这是新手最容易踩的坑。CANN 中存在两套错误码体系数值型返回码aclError类型如107000参数非法、107001Device ID 无效定义在 rt_error_codes.h 中6位字符错误码形如EE1023第一位表示级别E 错误 / W 告警 / I 提示第二位表示模块后四位是错误编号。这类错误码在 docs/zh/error_code_ref/ 目录下有逐条解读。 错误码速查三类高频错误码解读遇到报错别慌先按前缀分类再查对应文档EE1xxx/EE4xxx/WE0xxx—— RuntimeRTS错误如参数非法、模型绑定失败、上下文无效等完整清单见 RTS-Errors.mdEH0xxx—— ACL 层错误绝大多数是参数非法或空指针见 ACL-Errors.mdEE1023资源不足—— Device 上 Stream / Event / Notify 等硬件调度资源耗尽的高频问题可先读 EE1023资源不足问题.md 中的 retCode 对照表。几个高频场景的快速入口现象大概率原因参考文档aclInit失败驱动/固件版本不匹配、设备未启动aclInit初始化失败常见原因排查.mdaclrtMalloc失败显存不足、内存碎片、地址空间限制aclrtMalloc内存申请失败常见原因.md算子输出全 0内存未初始化、数据类型不匹配、拷贝失败算子执行输出全0的常见原因排查.md⏱️ 异步错误定位接口返回成功任务却失败了这是 CANN Runtime 错误排查中最典型的问题详见 如何获取和解读Runtime异步错误码.md。掌握下面 4 个方法基本可以覆盖所有场景方法 1下发后立即同步—— 在异步任务后立即调用同步接口当场拿到真实执行结果aclrtMemcpyAsync(devPtr, devSize, hostPtr, hostSize, ACL_MEMCPY_HOST_TO_DEVICE, stream); // 立即同步暴露 Device 侧的真实错误 aclError error aclrtSynchronizeStream(stream); if (error ! ACL_RT_SUCCESS) { printf(Async task failed: %d, msg: %s\n, error, aclGetRecentErrMsg()); }方法 2用错误查询接口兜底——aclrtPeekAtLastError查看但不重置和aclrtGetLastError获取并重置可查询当前线程累积的 Runtime 错误。方法 3aclGetRecentErrMsg()拿人类可读的错误描述—— 配合错误码一起打印诊断信息立刻完整。方法 4开启遇错即停模式—— 用aclrtSetStreamFailureMode(stream, ACL_STOP_ON_FAILURE)让首个错误发生时就停止执行避免后续任务覆盖现场。若 Stream 上任务很多难以定位可参考 遇错即停模式下错误定位方法.md 中的分段同步 Event 标记任务边界技巧。 官方提供了一个错误处理基础样例演示了如何统一检查 ACL 返回值并组合使用上述诊断接口example/0_quickstart/1_error_handling/main.cpp。 plog日志分析四步锁定 Device 侧异常当错误码只是告诉你出错了而 plog 日志会告诉你错在哪、为什么错。plog 是 Host 侧应用类日志默认路径为$HOME/ascend/log/[run|debug]/plog/plog-pid_*.log日志格式为[Level] ModuleName(PID,PName):DateTimeMS [FileName:LineNumber] LogContent格式详解见 log_overview.md。完整方法见 如何通过plog日志定位Device侧异常.md核心是四个 grepgrep Task run failed plog.log # ① 定位失败任务device_id / stream_id / task_id grep fault kernel_name plog.log # ② 定位失败内核fault kernel_nameAdd_xxx grep retCode plog.log # ③ 分析错误码如 retCode0x31 [vector core exception] grep The error from device plog.log # ④ 查看芯片/Die/核心级异常详情一条典型日志的解读示例[ERROR] RUNTIME(2082291,python3):2024-07-04-14:14:25.050.365 [davinic_kernel_task.cc:1219] PreCheckTaskErr: Kernel task happen error, retCode0x31, [vector core exception]. fault kernel_nameAdd_ee98c6628030785f610b924ab1557b31_high_performance_210000000解读要点retCode0x31表示AI 向量核aivec异常常见于数组越界或 tiling 参数计算错误fault kernel_name直接点名了出错的算子内核后缀中的210000000是 tiling key可用于反查算子实现。常见日志特征对照表日志特征异常类型排查方向retCode0x31, [vector core exception]向量核异常数组越界、内存分配不足、tiling 计算错误errType0x2 (task timeout)任务超时死循环、计算量过大、硬件资源不足retCode0x7020023Alloc Stream failedStream 资源不足减少并发 Stream / 检查资源泄漏retCode0x7110019async copy tasks 达上限异步拷贝队列满减小numBatches等批量参数如果默认日志信息不够可通过环境变量提升详细度export ASCEND_GLOBAL_LOG_LEVEL0DEBUG 级并可用ASCEND_LOG_PRINT_TO_STDOUT1让日志直接输出到终端。✅ 一套完整的排查清单收藏备用看返回值每个 ACL API 调用后检查aclError是否等于ACL_RT_SUCCESS立即同步异步任务后用aclrtSynchronizeStream/aclrtSynchronizeDevice暴露真实错误查错误描述aclGetRecentErrMsg()打印人类可读信息对照 error_code_ref 目录定位含义开遇错即停调试期用ACL_STOP_ON_FAILURE保住现场生产环境再权衡grep plog按任务 → 内核 → retCode → 设备详情四步深挖 Device 侧异常提升日志级别信息不足时切换 DEBUG 级别重跑一次。掌握这套流程从莫名失败到精确定位通常只需要 10 分钟。更多场景可继续参考 docs/zh/FAQ/ 下的 Stream 同步、多 Device 跨设备下发等专题以及 api_ref/13_exception_handling.md 中的官方异常处理 API 说明。【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考