CANN opbase EZ1005 错误码详解算子 JSON 文件解析失败File Operation Error Parse的排查与修复【免费下载链接】opbase本项目是CANN算子库的基础框架库为算子提供公共依赖文件和基础调度能力。项目地址: https://gitcode.com/cann/opbase导读EZ1005 是 CANN opbase算子库基础框架库Nnopbase 错误系列中针对文件解析失败场景定义的标准错误码当框架在加载、解析算子 JSON 配置文件内置算子包或自定义算子包中的 kernel 配置文件时发现文件内容损坏、结构非法便会抛出形如Failed to parse file %s. Reason: %s.的错误。本文以关联文档 EZ1005-File_Operation_Error_Parse.md 为骨架结合 opbase 仓库中错误码的定义、上报宏与 JSON 解析源码完整讲解该错误码的报文格式、触发链路、常见原因以及系统化的排查与修复步骤帮助你快速定位算子包安装或加载阶段出现的配置解析异常。错误码速览属性内容错误码EZ1005错误类型Nnopbase ErrorsFile Operation Error Parse错误报文模板Failed to parse file %s. Reason: %s.占位符含义%s按顺序文件名称、错误原因上报接口OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE_WITH_INVALID_CONTENT典型返回码ACLNN_ERR_INNER_LOAD_JSON_FAILED对应文档EZ1005-File_Operation_Error_Parse.md该错误码在框架的错误注册表中同样有完整登记位于 op_error_manager.cpp其中Arglist为file, reason并预置了建议项可能原因是自定义算子 JSON 文件损坏或内置算子 JSON 文件损坏解决方案是重新安装对应的算子包。错误报文格式与典型示例报文模板解析错误信息统一遵循以下模板Failed to parse file %s. Reason: %s.其中两个占位符的语义为第一个%s被解析失败的文件完整路径例如/home/developer/Ascend/cann-9.0.0/opp/built-in/op_impl/ai_core/tbe/config/ascendxxx/aic-ascendxxxx-ops-info-oam.json第二个%s解析失败的具体原因例如The operator JSON file is not in the standard key-value structure.文档中的真实错误示例关联文档给出的典型报错如下Failed to parse file /home/developer/Ascend/cann-9.0.0/opp/built-in/op_impl/ai_core/tbe/config/ascendxxx/aic-ascendxxxx-ops-info-oam.json. Reason: The operator JSON file is not in the standard key-value structure.从路径可以判断该报错发生在加载oppOperator Platform Package内置算子包中的内核配置文件阶段。以aic-开头、以-ops-info-oam.json结尾的文件是内置算子内核信息配置文件其内容必须是标准的键值key-value结构——即最外层是一个 JSON 对象。框架在解析时会对解析结果做结构校验一旦发现最外层不是 JSON 对象例如文件损坏后只剩数组、标量或非法片段就会以该错误码上报。与 EZ1004 的区分Nnopbase 错误系列中还有同名的 EZ1004EZ1004-File_Operation_Error_Parse.md两者共享完全相同的报文模板Failed to parse file %s. Reason: %s.区别在于EZ1004解析过程中抛出底层异常如 nlohmann/json 的json.exception.parse_error常见于 JSON 语法错误、引号不配对、缺少逗号等由宏OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE上报原因直接来自异常对象的what()描述EZ1005JSON语法解析成功但内容结构不合法最外层不是标准键值结构由宏OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE_WITH_INVALID_CONTENT上报原因通常是框架自定义的语义描述。两者在排查时要分开对待EZ1004 偏重 JSON 语法层面EZ1005 偏重结构/语义层面。源码级原理EZ1005 是如何产生的错误码上报宏EZ1005 的报文在上报宏中直接拼接定义于 nnopbase_error_msg.h#define OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE_WITH_INVALID_CONTENT(file, reason) \ do { \ std::string msg std::string(Failed to parse file ) file . Reason: reason .; \ const std::vectorconst char* msgKey {file, reason}; \ const std::vectorconst char* msgValue {file, reason}; \ OP_LOGE_WITHOUT_REPORT(EZ1005, %s, msg.c_str()); \ REPORT_PREDEFINED_ERR_MSG(EZ1005, msgKey, msgValue); \ } while (false)该宏做了两件事通过OP_LOGE_WITHOUT_REPORT(EZ1005, ...)在运行日志中记录带错误码EZ1005的错误信息通过REPORT_PREDEFINED_ERR_MSG(EZ1005, msgKey, msgValue)将file与reason两个键值对上报给上层错误处理通道供工具链与调用方获取结构化错误信息。从源码可以看出该错误码专门为文件内容非法invalid content设计与普通解析异常EZ1004在语义上做了明确区分。触发位置 1内核库初始化阶段的批量 JSON 加载在算子内核库OpKernelLib初始化时框架会依次扫描自定义算子路径、vendors 路径与内置路径下的全部.json配置文件逐个解析并合并。相关实现位于 op_kernel_lib.cppaclnnStatus OpKernelLib::Initialize() { ... for (const auto filePath : opKernelLibFilePaths) { OP_LOGI(OpKernelLib start parse json file: %s., filePath.c_str()); try { std::ifstream f(filePath); allKernelsJson_.merge_patch(Json::parse(f)); OP_CHECK(allKernelsJson_.is_object(), OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE_WITH_INVALID_CONTENT( filePath.c_str(), The operator JSON file is not in the standard key-value structure), return ACLNN_ERR_INNER_LOAD_JSON_FAILED); } catch (std::exception e) { OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE(filePath.c_str(), e.what()); return ACLNN_ERR_INNER_LOAD_JSON_FAILED; } } initFlag_ true; ... }这段代码完整对应了错误示例中的两条 Reason 路径EZ1005 路径Json::parse语法解析成功但merge_patch之后allKernelsJson_.is_object()为 false最外层不是对象即不是标准键值结构则抛出 EZ1005EZ1004 路径Json::parse本身抛出std::exceptionJSON 语法错误则抛出 EZ1004原因取自e.what()。其中文件名来源自定义算子路径通过 GetCustomOppFilePaths() 扫描custom_impl下对应 SoC 目录的 JSON 文件vendors 路径通过GetOppVendorsFilePaths()扫描ASCEND_OPP_PATH/vendors/vendorName下的 JSON 文件内置路径通过GetBuiltInFilePaths()扫描内置 opp 包中的 JSON 文件。三者合并后统一解析因此无论是内置还是自定义算子包中的 JSON 文件损坏都可能在此处触发 EZ1005。触发位置 2算子二进制信息BinInfo解析除了内核库初始化单个算子的二进制信息 JSON 解析同样会触发 EZ1005/EZ1004在 op_kernel.cpp 中当解析的算子 JSON 缺少必需字段kernelName时会以The operator JSON file does not contain the kernel name为原因上报 EZ1005在 op_kernel.cpp 中解析配置文件 JSON 时若抛出异常则上报 EZ1004若内容结构非法非对象则上报 EZ1005在 kernel_mgr.cpp 与 indv_executor.cpp 中也有对算子 bin 信息 JSON 解析失败的上报逻辑。这说明 EZ1005 并不仅限于 opp 包整体加载算子粒度的 JSON 配置如 kernel 描述文件、二进制信息配置文件解析异常同样会走到该错误码。可能原因分析结合关联文档与源码实现EZ1005 的触发原因可以归纳为两类自定义算子 JSON 文件损坏开发者安装的自定义算子包Custom Operator Package中custom_impl目录下的 JSON 内核配置文件在打包、传输、磁盘写入过程中被破坏导致文件内容不再是合法的标准键值结构。这类文件由 GetCustomOppFilePaths() 收集并参与解析。内置算子 JSON 文件损坏系统内置 opp 包中的 JSON 文件如示例中的aic-ascendxxxx-ops-info-oam.json损坏。常见诱因包括升级/回退过程中包文件未完整替换、磁盘损坏、安装中断如断电导致文件截断、或不同版本的 opp 包文件被混用。从代码结构看无论上述哪种文件损坏最终都会在 OpKernelLib::Initialize() 的统一 JSON 解析循环中被拦截并上报。解决方案与排查步骤方案一重新安装自定义算子包若报错路径位于自定义算子安装目录通常形如.../opp/vendors/vendorName/op_impl/...或自定义custom_impl路径下按以下步骤处理先确认该文件在安装介质如安装包、压缩包中的原始内容是否完好排除打包源本身损坏的可能卸载当前已安装的自定义算子包重新执行自定义算子包的安装流程安装完成后核对报错路径下的 JSON 文件是否已恢复完整重新运行触发场景算子加载或调用确认 EZ1005 不再出现。方案二重新安装内置算子包若报错路径位于内置 opp 包如示例中的.../opp/built-in/...下按以下步骤处理记录报错中给出的完整文件路径与错误原因这是定位的关键线索检查安装环境的磁盘剩余空间与文件系统状态排除磁盘写满或文件系统异常导致的文件截断使用 CANN 提供的卸载/重装流程重新安装内置算子包opp 包确保升级或修复过程中文件被完整替换若重装后问题仍存在可进一步比对报错文件与正常环境中同名文件的字节数、哈希值确认是否是包内容本身的问题重新触发场景验证。通用定位建议区分 EZ1004 与 EZ1005报错 Reason 为The operator JSON file is not in the standard key-value structure或类似语义描述时属于 EZ1005结构非法报错 Reason 形如[json.exception.parse_error.101] parse error at line ...时属于 EZ1004语法错误两者处理侧重不同。检查文件完整性可用jq等工具对被报错文件执行jq . file若输出报错则文件确已损坏jq .成功后检查首字符是否为{确认最外层是否为对象结构。排查混装问题确认自定义算子包与内置算子包的版本配套避免不同版本、不同 SoC 目录下的 JSON 文件混用导致解析到不兼容内容。扩展阅读错误码完整索引Nnopbase-Errors.md可对照查看 EZ1001~EZ1014 各错误码的语义边界同名语法解析错误码EZ1004EZ1004-File_Operation_Error_Parse.md错误码注册表实现op_error_manager.cpp上报宏定义nnopbase_error_msg.hJSON 批量解析核心逻辑op_kernel_lib.cpp算子级 JSON 解析与字段校验op_kernel.cpp。总结EZ1005 是 CANN opbase 在算子 JSON 配置文件结构不合法时给出的标准化错误码报文中的文件名与原因两个占位符分别指明了损坏的文件与具体的结构问题。理解其与 EZ1004 的区分、掌握源码中 OpKernelLib::Initialize() 的解析链路再结合重新安装自定义算子包 / 重新安装内置算子包两条处置路径即可快速恢复算子加载环境。若在排查中遇到文件反复损坏还应对磁盘健康状态与安装流程进行整体检查。【免费下载链接】opbase本项目是CANN算子库的基础框架库为算子提供公共依赖文件和基础调度能力。项目地址: https://gitcode.com/cann/opbase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CANN opbase EZ1005 错误码详解：算子 JSON 文件解析失败（File Operation Error Parse）的排查与修复
CANN opbase EZ1005 错误码详解算子 JSON 文件解析失败File Operation Error Parse的排查与修复【免费下载链接】opbase本项目是CANN算子库的基础框架库为算子提供公共依赖文件和基础调度能力。项目地址: https://gitcode.com/cann/opbase导读EZ1005 是 CANN opbase算子库基础框架库Nnopbase 错误系列中针对文件解析失败场景定义的标准错误码当框架在加载、解析算子 JSON 配置文件内置算子包或自定义算子包中的 kernel 配置文件时发现文件内容损坏、结构非法便会抛出形如Failed to parse file %s. Reason: %s.的错误。本文以关联文档 EZ1005-File_Operation_Error_Parse.md 为骨架结合 opbase 仓库中错误码的定义、上报宏与 JSON 解析源码完整讲解该错误码的报文格式、触发链路、常见原因以及系统化的排查与修复步骤帮助你快速定位算子包安装或加载阶段出现的配置解析异常。错误码速览属性内容错误码EZ1005错误类型Nnopbase ErrorsFile Operation Error Parse错误报文模板Failed to parse file %s. Reason: %s.占位符含义%s按顺序文件名称、错误原因上报接口OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE_WITH_INVALID_CONTENT典型返回码ACLNN_ERR_INNER_LOAD_JSON_FAILED对应文档EZ1005-File_Operation_Error_Parse.md该错误码在框架的错误注册表中同样有完整登记位于 op_error_manager.cpp其中Arglist为file, reason并预置了建议项可能原因是自定义算子 JSON 文件损坏或内置算子 JSON 文件损坏解决方案是重新安装对应的算子包。错误报文格式与典型示例报文模板解析错误信息统一遵循以下模板Failed to parse file %s. Reason: %s.其中两个占位符的语义为第一个%s被解析失败的文件完整路径例如/home/developer/Ascend/cann-9.0.0/opp/built-in/op_impl/ai_core/tbe/config/ascendxxx/aic-ascendxxxx-ops-info-oam.json第二个%s解析失败的具体原因例如The operator JSON file is not in the standard key-value structure.文档中的真实错误示例关联文档给出的典型报错如下Failed to parse file /home/developer/Ascend/cann-9.0.0/opp/built-in/op_impl/ai_core/tbe/config/ascendxxx/aic-ascendxxxx-ops-info-oam.json. Reason: The operator JSON file is not in the standard key-value structure.从路径可以判断该报错发生在加载oppOperator Platform Package内置算子包中的内核配置文件阶段。以aic-开头、以-ops-info-oam.json结尾的文件是内置算子内核信息配置文件其内容必须是标准的键值key-value结构——即最外层是一个 JSON 对象。框架在解析时会对解析结果做结构校验一旦发现最外层不是 JSON 对象例如文件损坏后只剩数组、标量或非法片段就会以该错误码上报。与 EZ1004 的区分Nnopbase 错误系列中还有同名的 EZ1004EZ1004-File_Operation_Error_Parse.md两者共享完全相同的报文模板Failed to parse file %s. Reason: %s.区别在于EZ1004解析过程中抛出底层异常如 nlohmann/json 的json.exception.parse_error常见于 JSON 语法错误、引号不配对、缺少逗号等由宏OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE上报原因直接来自异常对象的what()描述EZ1005JSON语法解析成功但内容结构不合法最外层不是标准键值结构由宏OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE_WITH_INVALID_CONTENT上报原因通常是框架自定义的语义描述。两者在排查时要分开对待EZ1004 偏重 JSON 语法层面EZ1005 偏重结构/语义层面。源码级原理EZ1005 是如何产生的错误码上报宏EZ1005 的报文在上报宏中直接拼接定义于 nnopbase_error_msg.h#define OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE_WITH_INVALID_CONTENT(file, reason) \ do { \ std::string msg std::string(Failed to parse file ) file . Reason: reason .; \ const std::vectorconst char* msgKey {file, reason}; \ const std::vectorconst char* msgValue {file, reason}; \ OP_LOGE_WITHOUT_REPORT(EZ1005, %s, msg.c_str()); \ REPORT_PREDEFINED_ERR_MSG(EZ1005, msgKey, msgValue); \ } while (false)该宏做了两件事通过OP_LOGE_WITHOUT_REPORT(EZ1005, ...)在运行日志中记录带错误码EZ1005的错误信息通过REPORT_PREDEFINED_ERR_MSG(EZ1005, msgKey, msgValue)将file与reason两个键值对上报给上层错误处理通道供工具链与调用方获取结构化错误信息。从源码可以看出该错误码专门为文件内容非法invalid content设计与普通解析异常EZ1004在语义上做了明确区分。触发位置 1内核库初始化阶段的批量 JSON 加载在算子内核库OpKernelLib初始化时框架会依次扫描自定义算子路径、vendors 路径与内置路径下的全部.json配置文件逐个解析并合并。相关实现位于 op_kernel_lib.cppaclnnStatus OpKernelLib::Initialize() { ... for (const auto filePath : opKernelLibFilePaths) { OP_LOGI(OpKernelLib start parse json file: %s., filePath.c_str()); try { std::ifstream f(filePath); allKernelsJson_.merge_patch(Json::parse(f)); OP_CHECK(allKernelsJson_.is_object(), OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE_WITH_INVALID_CONTENT( filePath.c_str(), The operator JSON file is not in the standard key-value structure), return ACLNN_ERR_INNER_LOAD_JSON_FAILED); } catch (std::exception e) { OP_LOGE_FOR_FILE_OPERATION_ERROR_PARSE(filePath.c_str(), e.what()); return ACLNN_ERR_INNER_LOAD_JSON_FAILED; } } initFlag_ true; ... }这段代码完整对应了错误示例中的两条 Reason 路径EZ1005 路径Json::parse语法解析成功但merge_patch之后allKernelsJson_.is_object()为 false最外层不是对象即不是标准键值结构则抛出 EZ1005EZ1004 路径Json::parse本身抛出std::exceptionJSON 语法错误则抛出 EZ1004原因取自e.what()。其中文件名来源自定义算子路径通过 GetCustomOppFilePaths() 扫描custom_impl下对应 SoC 目录的 JSON 文件vendors 路径通过GetOppVendorsFilePaths()扫描ASCEND_OPP_PATH/vendors/vendorName下的 JSON 文件内置路径通过GetBuiltInFilePaths()扫描内置 opp 包中的 JSON 文件。三者合并后统一解析因此无论是内置还是自定义算子包中的 JSON 文件损坏都可能在此处触发 EZ1005。触发位置 2算子二进制信息BinInfo解析除了内核库初始化单个算子的二进制信息 JSON 解析同样会触发 EZ1005/EZ1004在 op_kernel.cpp 中当解析的算子 JSON 缺少必需字段kernelName时会以The operator JSON file does not contain the kernel name为原因上报 EZ1005在 op_kernel.cpp 中解析配置文件 JSON 时若抛出异常则上报 EZ1004若内容结构非法非对象则上报 EZ1005在 kernel_mgr.cpp 与 indv_executor.cpp 中也有对算子 bin 信息 JSON 解析失败的上报逻辑。这说明 EZ1005 并不仅限于 opp 包整体加载算子粒度的 JSON 配置如 kernel 描述文件、二进制信息配置文件解析异常同样会走到该错误码。可能原因分析结合关联文档与源码实现EZ1005 的触发原因可以归纳为两类自定义算子 JSON 文件损坏开发者安装的自定义算子包Custom Operator Package中custom_impl目录下的 JSON 内核配置文件在打包、传输、磁盘写入过程中被破坏导致文件内容不再是合法的标准键值结构。这类文件由 GetCustomOppFilePaths() 收集并参与解析。内置算子 JSON 文件损坏系统内置 opp 包中的 JSON 文件如示例中的aic-ascendxxxx-ops-info-oam.json损坏。常见诱因包括升级/回退过程中包文件未完整替换、磁盘损坏、安装中断如断电导致文件截断、或不同版本的 opp 包文件被混用。从代码结构看无论上述哪种文件损坏最终都会在 OpKernelLib::Initialize() 的统一 JSON 解析循环中被拦截并上报。解决方案与排查步骤方案一重新安装自定义算子包若报错路径位于自定义算子安装目录通常形如.../opp/vendors/vendorName/op_impl/...或自定义custom_impl路径下按以下步骤处理先确认该文件在安装介质如安装包、压缩包中的原始内容是否完好排除打包源本身损坏的可能卸载当前已安装的自定义算子包重新执行自定义算子包的安装流程安装完成后核对报错路径下的 JSON 文件是否已恢复完整重新运行触发场景算子加载或调用确认 EZ1005 不再出现。方案二重新安装内置算子包若报错路径位于内置 opp 包如示例中的.../opp/built-in/...下按以下步骤处理记录报错中给出的完整文件路径与错误原因这是定位的关键线索检查安装环境的磁盘剩余空间与文件系统状态排除磁盘写满或文件系统异常导致的文件截断使用 CANN 提供的卸载/重装流程重新安装内置算子包opp 包确保升级或修复过程中文件被完整替换若重装后问题仍存在可进一步比对报错文件与正常环境中同名文件的字节数、哈希值确认是否是包内容本身的问题重新触发场景验证。通用定位建议区分 EZ1004 与 EZ1005报错 Reason 为The operator JSON file is not in the standard key-value structure或类似语义描述时属于 EZ1005结构非法报错 Reason 形如[json.exception.parse_error.101] parse error at line ...时属于 EZ1004语法错误两者处理侧重不同。检查文件完整性可用jq等工具对被报错文件执行jq . file若输出报错则文件确已损坏jq .成功后检查首字符是否为{确认最外层是否为对象结构。排查混装问题确认自定义算子包与内置算子包的版本配套避免不同版本、不同 SoC 目录下的 JSON 文件混用导致解析到不兼容内容。扩展阅读错误码完整索引Nnopbase-Errors.md可对照查看 EZ1001~EZ1014 各错误码的语义边界同名语法解析错误码EZ1004EZ1004-File_Operation_Error_Parse.md错误码注册表实现op_error_manager.cpp上报宏定义nnopbase_error_msg.hJSON 批量解析核心逻辑op_kernel_lib.cpp算子级 JSON 解析与字段校验op_kernel.cpp。总结EZ1005 是 CANN opbase 在算子 JSON 配置文件结构不合法时给出的标准化错误码报文中的文件名与原因两个占位符分别指明了损坏的文件与具体的结构问题。理解其与 EZ1004 的区分、掌握源码中 OpKernelLib::Initialize() 的解析链路再结合重新安装自定义算子包 / 重新安装内置算子包两条处置路径即可快速恢复算子加载环境。若在排查中遇到文件反复损坏还应对磁盘健康状态与安装流程进行整体检查。【免费下载链接】opbase本项目是CANN算子库的基础框架库为算子提供公共依赖文件和基础调度能力。项目地址: https://gitcode.com/cann/opbase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考