CANN Runtime 错误码 EP0004 全解析Dump 配置文件解析失败的定位与修复指南【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime导读EP0004File Operation Error - Parse是 CANN Runtime 中 adump 数据采集组件上报的配置文件解析失败错误码用于标识acl.json等 Dump 配置 JSON 文件无法通过语法解析的场景。本文基于开源仓库cann/runtime中的错误码参考文档结合src/dfx/adump下的真实实现与单元测试完整拆解该错误码的报文格式、触发链路、典型原因与排查方法。读者阅读后可准确解读 EP0004 报错中的每个占位符含义并据此快速修复异常的 Dump 配置文件。错误码概览EP 系列在 Dump 错误体系中的定位EP0004 属于 DUMP ErrorsDump 错误错误类在 Dump 错误码索引 中与其姊妹错误码共同构成一套完整的 Dump 配置校验错误体系错误码错误标题语义EP0001Config Error配置项内容无效EP0002Config Error配置项取值无效给出期望值EP0003Config Error配置项取值无效给出原因EP0004File Operation Error - Parse配置文件解析失败EP0005Config Error配置项之间存在冲突EP0006Invalid Argument参数取值无效EP0007Invalid Argument - Null Pointer参数为空指针EP0008Invalid Argument - API Call SequenceAPI 调用顺序错误从语义上看EP0004 是其中唯一一个面向文件整体解析而非单个配置项的错误码当 Dump 配置 JSON 文件在语法层面无法被解析时触发而字段类型、取值、冲突等语义层面的问题则分别由 EP0001/EP0002/EP0003/EP0005 负责。这一分工可以在仓库的错误码注册表中得到直接印证见 error_code.json{ errClass: DUMP Errors, errTitle: File_Operation_Error_Parse, ErrCode: EP0004, ErrMessage: Failed to parse file %s. Reason: %s., Arglist: path,reason, suggestion: { Possible Cause: N/A, Solution: N/A } }错误信息格式与字段含义EP0004 的标准报错格式见 官方文档Failed to parse file %s. Reason: %s.两个占位符%s的含义依次为占位符含义对应 Arglist第 1 个%s配置文件路径file name / pathpath第 2 个%s解析失败的具体原因error cause / reasonreason官方给出的报错示例如下Failed to parse file /home/test_dump/acl.json. Reason: [json.exception.type_error.302] type must be array, but is string.在这个例子中/home/test_dump/acl.json是待解析的配置文件路径而[json.exception.type_error.302] type must be array, but is string则是底层 JSON 解析器抛出的异常描述。从异常前缀json.exception.type_error.302可以推断解析工作由 nlohmann/json 库执行——这一点与下文源码实现中的调用保持一致。触发链路EP0004 从哪里来EP0004 并非由人工手写抛出而是由 adump 组件在 Dump 配置转换流程中自动上报。整条链路如下1. 上报宏定义EP0004 的上报入口封装在 adump_error_manager.h 中// EP0004 Parse Error Report Macro - Inline for performance #define REPORT_EP0004_PARSE_ERROR(moduleName, reason, configPath) \ do { \ IDE_LOGE([%s] Parse failed: %s, moduleName, ADUMP_TO_CSTR(reason)); \ ADUMP_INPUT_ERROR( \ EP0004, std::vectorstd::string({path, reason}), std::vectorstd::string({configPath, reason})); \ } while (0)该宏做了两件事通过IDE_LOGE在本地日志中记录[模块名] Parse failed: 原因通过ADUMP_INPUT_ERROR将错误码EP0004及参数path配置文件路径、reason解析原因上报到错误管理模块最终按error_code.json中的模板格式化输出。注意宏体中传入的path参数名为configPath说明该错误码的文件实际上特指 Dump 配置文件。2. JSON 语法解析JsonParser::ParseJsonFromMemoryEP0004 的根因在于 JSON 语法解析失败解析动作由 json_parser.cpp 中的ParseJsonFromMemory完成int32_t JsonParser::ParseJsonFromMemory( const char* dumpConfigData, size_t dumpConfigSize, nlohmann::json js, std::string errMsg) { errMsg.clear(); if ((dumpConfigData nullptr) || (dumpConfigSize 0U)) { errMsg Invalid input parameters; IDE_LOGD(Parse json from memory failed: invalid input parameters.); return ADUMP_INPUT_FAILED; } try { std::string_view jsonString(dumpConfigData, dumpConfigSize); IDE_LOGI(Parse json string: %.*s, static_castint(jsonString.size()), jsonString.data()); js nlohmann::json::parse(jsonString); IDE_LOGD(Parse json successfully.); return ADUMP_SUCCESS; } catch (const nlohmann::json::parse_error e) { errMsg e.what(); IDE_LOGE(JSON parse error: %s, e.what()); } catch (const std::exception e) { errMsg e.what(); IDE_LOGE(Unexpected error while parsing JSON from memory: %s, e.what()); } return ADUMP_INPUT_FAILED; }关键实现细节使用nlohmann/json库的nlohmann::json::parse对配置内存数据进行解析这与报错示例中的json.exception.type_error.302异常前缀完全吻合配置数据为空空指针或长度为 0时errMsg被置为Invalid input parameters捕获nlohmann::json::parse_error纯语法错误和其他std::exception运行时异常如类型错误异常描述e.what()会原样写入errMsg作为 EP0004 报错的 Reason 部分透传出来。3. 错误上报入口DumpConfigConverter::Convertdump_config_converter.cpp 中的Convert是 Dump 配置转换的主流程也是 EP0004 仅有的两处上报点上报点 1JSON 语法解析失败nlohmann::json js; std::string errMsg; needDump false; int32_t ret JsonParser::ParseJsonFromMemory(dumpConfigData_, dumpConfigSize_, js, errMsg); if (ret ! ADUMP_SUCCESS) { REPORT_EP0004_PARSE_ERROR(Convert, errMsg, configPath_); return ADUMP_FAILED; }当ParseJsonFromMemory返回失败时立即上报 EP0004Reason 即为解析器返回的errMsg随后整个配置转换流程以失败结束。上报点 2后续处理中的运行时异常try { ... dumpJs_ js.at(ADUMP_DUMP); ... } catch (const std::exception e) { REPORT_EP0004_PARSE_ERROR(Convert, std::string(e.what()), configPath_); return ADUMP_FAILED; }即使在语法解析通过之后若对 JSON 内容的后续访问如js.at(ADUMP_DUMP)取值、类型转换等抛出std::exception典型的如官方示例中的type_error.302期望数组实际是字符串同样会走 EP0004 上报路径。由此可以归纳出触发 EP0004 的完整条件Dump 配置文件在语法或底层类型层面无法被 nlohmann/json 正常解析/访问。而字段语义层面的校验如dump必须是对象、dump_list必须是数组等则走 EP0001 路径两者在源码中分工明确。典型报错场景与原因分类结合 单元测试用例TestJsonSyntaxErrorsEP0004 覆盖的典型失败场景包括输入配置JSON问题描述期望错误码{dump: {dump_op_switch: on花括号未闭合JSON 语法不完整EP0004{dump: {dump_list: [{model_name: model1})方括号/圆括号混用、括号不匹配EP0004asdf{完全不是合法 JSONEP0004测试辅助函数TestFailureHelper同文件会构造DumpConfigConverter并调用Convert断言返回值为ADUMP_FAILED且上报的错误码正是EP0004void TestFailureHelper( const std::string configData, const std::string configPath, const std::string expectedErrorCode) { ... DumpConfigConverter converter{configData.c_str(), configData.size(), configPath.c_str()}; int32_t ret converter.Convert(dumpType, dumpConfig, IsNeedDump, dumpDfxConfig); EXPECT_EQ(ret, ADUMP_FAILED); EXPECT_FALSE(IsNeedDump); EXPECT_EQ(GetLastReportedErrorCode(), expectedErrorCode); }需要注意的是同一测试文件中另有TestDumpFieldTypeErrorsL483-L492其中{dump: true}、{dump: []}等语法合法但类型错误的输入期望的是 EP0001 而非 EP0004。这说明凡是能通过 JSON 语法解析的问题都不会报 EP0004EP0004 严格对应文件本身无法被解析这一层。排查与修复步骤按照官方文档的解决方法修复思路是按照 Reason 中的提示检查并修改。结合源码实现可以细化出以下排查路径步骤 1先读 Reason区分错误大类EP0004 报错中的 Reason 直接来自 nlohmann/json 的异常描述常见形态包括[json.exception.parse_error.101] parse error at line X, column Y: ...—— 纯语法错误通常是括号不匹配、引号未闭合、尾逗号、非法字符等[json.exception.type_error.302] type must be array, but is string—— JSON 合法但代码期望的 JSON 类型与实际类型不一致如官方示例Invalid input parameters—— 配置文件内容为空空指针或长度为 0。步骤 2检查 JSON 语法与括号配对对配置文件做基本的语法自查花括号{}、方括号[]、引号必须成对且闭合键名必须用双引号包裹不允许尾随逗号如a: 1,}整体必须是单个合法的 JSON 值对象或数组。仓库中的合法示例可参考 0_adump_args/acl.json{dump: {dump_path: ./, dump_list: [], dump_op_switch: on, dump_data: tensor}}步骤 3核对配置项取值是否匹配期望类型当 Reason 中出现type_error时说明 JSON 语法虽合法但某个字段的类型与解析代码期望不符。adump 解析代码dump_config_converter.cpp对dump对象内各字段的读取方式决定了其期望类型字符串型字段直接取值而dump_stats、dump_list、blacklist的pos等字段则要求为字符串数组。类型不匹配会抛异常并触发 EP0004。步骤 4确认整体结构配置文件的顶层应包含dump对象ADUMP_DUMP键Dump 配置项均位于该对象内。若缺失dump键Convert会直接返回成功而不做 Dump不会触发 EP0004。步骤 5修改后重跑验证修正配置后重新触发采集确认不再出现Failed to parse file ...报文。若解析通过后仍有问题报错码会切换为 EP0001字段类型/内容、EP0002取值不在期望集合内、EP0003取值非法并给出原因或 EP0005配置项冲突此时需参照对应错误码文档继续排查。与其他 EP 错误码的边界区分在实际排障中最容易与 EP0004 混淆的是 EP0001二者的边界如下EP0004文件整体无法解析JSON 语法错误、解析期类型异常、内容为空。对应ParseJsonFromMemory失败或Convert的try块内抛出的std::exceptionEP0001文件能解析但配置项的类型或内容非法如dump不是对象、dump_path不是字符串由CheckDumpFieldTypes、CheckDumpFieldValues等校验函数主动上报Reason 来自 adump_error_manager.h 中预定义的常量如This configuration item must be of the array type、The configuration item value is empty等EP0005文件能解析且字段合法但配置项之间存在互斥约束冲突Reason 模板同样定义在 adump_error_manager.h 中。简单记忆EP0004 是JSON 都读不了EP0001/0002/0003/0005 是JSON 读得了但内容不合法。测试验证与进一步阅读若希望复现 EP0004 的上报行为可直接查看 dump_config_converter_utest.cpp 中的TestJsonSyntaxErrors用例其错误码模板与参数格式化逻辑在 error_manager_stub.cpp 中有对应桩实现可供理解上报机制的端到端行为。进一步阅读建议EP0004 官方文档英文EP0004 官方文档中文Dump 错误码索引错误码注册表EP0004 上报宏与错误原因常量Dump 配置转换主流程JSON 解析器实现【免费下载链接】runtime本项目提供CANN运行时组件和维测功能组件。项目地址: https://gitcode.com/cann/runtime创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考