| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
feat: update mmpa & error_manager code format by .clang-format file Co-authored-by: likun104<likun104@h-partners.com> # message auto-generated for no-merge-commit merge: !3153 merge br_update_by_clang-format into master feat: update mmpa & error_manager code format by .clang-format file Created-by: likun104 Commit-by: likun104 Merged-by: cann-robot Description: # Pull Request ## 描述 根据.clang-format文件格式化mmpa & error_manager的代码 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1. 流水跑通过，且rdv跑通过 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!3153 | 2 个月前 | |
【PR】: 简要描述，同步abl/slog到runtime Co-authored-by: newstarzj<zhangjie230@huawei.com> # message auto-generated for no-merge-commit merge: !4148 merge master_log_sync into master 【PR】: 简要描述，同步abl/slog到runtime Created-by: newstarzj Commit-by: newstarzj;zhangjie Merged-by: cann-robot Description: ## 描述 【PR】: 简要描述，同步abl/slog到runtime ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 不涉及 ## 如何测试 UT ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4148 | 21 天前 | |
【PR】:新增AICPU OOM流同步错误码 Co-authored-by: G0rogoa<15357573068@163.com> # message auto-generated for no-merge-commit merge: !4241 merge codex/aicpu-oom-ee1024-discussion into master 【PR】:新增AICPU OOM流同步错误码 Created-by: moritaka1 Commit-by: G0rogoa Merged-by: cann-robot Description: # Pull Request ## 描述 由于OOM导致的aicpu算子流同步失败细分新增错误码，方便用户问题定位 1、OOM统计与缓存：在 ReportOomQueryProc 中，每次查询device的AICPU状态判断是否发生OOM，并统计OOM发生次数。统计规则为上升沿计数：从正常状态变为OOM状态算一次，持续OOM期间不重复计数，从OOM恢复后再OOM则再计一次。同时缓存最近10次查询结果（每秒一次查询，即最近10秒），用于超时报错时判断OOM是否是近期发生的。 2、超时报错信息修改： 在上报对外错误码的时候新增错误码。 3.原来日志显示的是aicpu timeout，但是错误码是EE9999内部错误，兜底修改 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 尝试在Device处于OOM状态时调用流同步观察错误码输出 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!4241 | 7 天前 | |
fix: 修复ErrorManager的并发缺陷(error_map_数据竞争 + is_init_/error_mode_锁外读写)(#842) Co-authored-by: KenChow<zhouchen53@huawei.com> # message auto-generated for no-merge-commit merge: !4364 merge fix_errmgr_thread_safety into master fix: 修复ErrorManager的并发缺陷(error_map_数据竞争 + is_init_/error_mode_锁外读写)(#842) Created-by: KenChow Commit-by: KenChow Merged-by: cann-robot Description: # Pull Request ## 描述 修复 ErrorManager 单例的三类并发缺陷。ErrorManager 以 GetInstance() 单例形式对外暴露 Init/Report* 接口，未声明需要调用方自行同步，但实现中 mutex_ 只保护了消息容器，未覆盖 error_map_/is_init_/error_mode_ 的全部访问点。 **缺陷 1：error_map_ 无锁读写（最严重，可崩溃）** 公开接口 ParseJsonFormatString 全程不持锁改写 error_map_，而它经由 RegisterFormatErrorMessage 在运行期可被任意线程调用；同时 ReportErrMessage 在锁外执行 error_map_.find，并把指向 map 内部的引用 error_info 带出锁一直用到组装 ErrorItem。 - find 与 emplace 并发会读到红黑树的调整中间态； - 高优先级注册路径的 it->second = error_info 会原地覆写正被读取的 std::string，可导致段错误。 IsUserDefinedErrorCode 同样在锁外读 error_map_。 **缺陷 2：is_init_ 先检查后初始化不是原子操作** 7 处上报接口在锁外读裸 bool 的 is_init_ 后各自调 Init()，多个线程可同时读到 false 并各自完整跑一遍 ParseJsonFile，造成重复解析 JSON。 **缺陷 3：error_mode_ 在锁外写** Init(mode) 在进入 Init(path) 的临界区之前就写裸 enum 的 error_mode_，与容器路由处的读之间没有 happens-before，构成数据竞争。且该写发生在校验解析结果之前，一次失败的 Init 会把错误消息粒度模式永久改成实际未生效的值。 **修改内容** 针对缺陷 1（error_map_ 无锁读写）： - ParseJsonFormatString 内部改为持 mutex_ 后再改写 error_map_；相应地 Init(path) 不再自己持锁，锁下沉到真正操作 error_map_ 的位置，顺带把文件读取移出临界区，也避免了递归加锁； - ReportErrMessage 持锁查找并把 ErrorInfoConfig 整体拷贝出来，出锁之后只使用副本，不再把指向表内部的引用带出锁； - IsUserDefinedErrorCode 持锁读 error_map_。 针对缺陷 2（is_init_ 先检查后初始化不是原子操作）： - is_init_ 改为原子变量，读写使用 acquire/release 语义； - 新增 init_mutex_ 与 EnsureInitialized()，用双重检查加锁把 7 处懒初始化收敛到一处，各调用点原有的返回值语义保持不变；加锁顺序固定为 init_mutex_ 在前、mutex_ 在后。 针对缺陷 3（error_mode_ 在锁外写）： - error_mode_ 改为原子变量，读写使用 acquire/release 语义； - Init(mode) 改为配置解析成功之后才写入模式，解析失败不再污染模式。 ## 变更类型 - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue https://gitcode.com/cann/runtime/issues/842 ## 如何测试 ### 单元测试 tests/ut/error_manager/testcase/error_manager_unittest.cc 新增 3 个用例： 1. ConcurrentRegisterAndReportErrMessage —— 一个线程持续调用 RegisterFormatErrorMessage 注册新错误码触发 error_map_ 插入，另一线程并发调用 ReportErrMessage，校验并发写入过程中不丢失任何已注册模板。 2. InitWithModeNotPolluteModeOnFailure —— 校验 Init(mode) 在非法模式和配置解析失败两种场景下都不改写 error_mode_。 3. ConcurrentLazyInitFromMultipleThreads —— 未初始化状态下 8 线程并发上报，覆盖 is_init_ 先检查后初始化的竞争。 执行方式： bash tests/build_ut.sh -u error_manager 需要说明两点：用例 2 在普通构建下就能拦截回归，因为测试程序同级目录没有 conf/error_manager/error_code.json，Init 必然失败，修复前会因模式被污染而用例失败；用例 1 和用例 3 覆盖的是数据竞争，普通构建下不会让用例失败，需要开启 ThreadSanitizer 编译才具备检出能力。经实测，AddressSanitizer 对这两处竞争检不出来。 ### 端到端验证 三个缺陷各有一个独立用例，只调用对外接口，不依赖任何检测工具，修复前后结果对比明确。 **验证一（对应缺陷 1）：并发注册错误码不丢失、不崩溃** 并发注册在现网是真实存在的：注册宏依托静态变量初始化，动态加载算子包或插件时就会执行；注册接口还通过 runtime_keeper 传给了驱动，可能由驱动线程回调。因此"一个线程注册、另一个线程上报"并非构造出来的极端场景。 构造方法：4 个线程各注册 6 万个互不重复的错误码，全部结束后由单线程逐个上报，检查每个注册过的错误码都能查到。判定标准是查不到的数量为 0，且进程没有异常退出。 修复前：连续 8 轮，其中 7 轮出现错误码丢失（每轮丢 1 到 4 个），1 轮进程段错误退出。 修复后：连续 8 轮全部通过，无丢失、无崩溃。 规模会影响复现概率：注册总量 8000 时约一半轮次能复现，24 万时 8 轮全部复现。建议按 24 万规模、重复 3 轮以上执行。 **验证二（对应缺陷 2）：首次并发上报只解析一次配置文件** 构造方法：进程启动后先注册若干模板但不触发初始化，然后 N 个线程同时首次上报，各自触发懒初始化，测量这一批上报的总耗时。修复前每个线程都会完整解析一遍 error_code.json（实测文件 119 KB），耗时随线程数线性增长；修复后只解析一次，耗时与线程数无关。判定标准是耗时不随线程数增长。 同一台机器实测： | 线程数 | 修复前 | 修复后 | | --- | --- | --- | | 4 | 14 毫秒 | 4 毫秒 | | 8 | 28 毫秒 | 3 毫秒 | | 16 | 56 毫秒 | 3 毫秒 | | 32 | 111 毫秒 | 4 毫秒 | 修复前耗时正比于线程数，正是重复解析配置文件的直接证据；修复后稳定在 3 到 4 毫秒。 **验证三（对应缺陷 3）：初始化失败后，错误消息记录粒度不被改变** 构造方法：先正常上报一次错误，让错误管理器完成初始化；把动态库所在目录上一层的 conf/error_manager/error_code.json 临时改名，让配置解析失败；调用 ErrMgrInit 设置为进程粒度，确认返回失败；恢复文件；起两个线程各上报一条不同的错误码，各自取回错误消息。判定标准是每个线程只能看到自己上报的那条。 修复前：接口返回失败，但粒度已被改成进程级，两个线程共用同一个消息容器，一个线程取回了两条消息（包含另一个线程的报错，且带有进程粒度特有的线程号后缀），另一个线程取回为空。连续 5 次全部失败。 修复后：两个线程各取各的，互不干扰，连续 5 次全部通过。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 已核对全部 12 个持 mutex_ 的函数，确认修改后不存在嵌套加锁；EnsureInitialized 的 init_mutex_ 与 mutex_ 加锁顺序单向，无死锁风险。 See merge request: cann/runtime!4364 | 15 天前 | |
fix: 修复ErrorManager的并发缺陷(error_map_数据竞争 + is_init_/error_mode_锁外读写)(#842) Co-authored-by: KenChow<zhouchen53@huawei.com> # message auto-generated for no-merge-commit merge: !4364 merge fix_errmgr_thread_safety into master fix: 修复ErrorManager的并发缺陷(error_map_数据竞争 + is_init_/error_mode_锁外读写)(#842) Created-by: KenChow Commit-by: KenChow Merged-by: cann-robot Description: # Pull Request ## 描述 修复 ErrorManager 单例的三类并发缺陷。ErrorManager 以 GetInstance() 单例形式对外暴露 Init/Report* 接口，未声明需要调用方自行同步，但实现中 mutex_ 只保护了消息容器，未覆盖 error_map_/is_init_/error_mode_ 的全部访问点。 **缺陷 1：error_map_ 无锁读写（最严重，可崩溃）** 公开接口 ParseJsonFormatString 全程不持锁改写 error_map_，而它经由 RegisterFormatErrorMessage 在运行期可被任意线程调用；同时 ReportErrMessage 在锁外执行 error_map_.find，并把指向 map 内部的引用 error_info 带出锁一直用到组装 ErrorItem。 - find 与 emplace 并发会读到红黑树的调整中间态； - 高优先级注册路径的 it->second = error_info 会原地覆写正被读取的 std::string，可导致段错误。 IsUserDefinedErrorCode 同样在锁外读 error_map_。 **缺陷 2：is_init_ 先检查后初始化不是原子操作** 7 处上报接口在锁外读裸 bool 的 is_init_ 后各自调 Init()，多个线程可同时读到 false 并各自完整跑一遍 ParseJsonFile，造成重复解析 JSON。 **缺陷 3：error_mode_ 在锁外写** Init(mode) 在进入 Init(path) 的临界区之前就写裸 enum 的 error_mode_，与容器路由处的读之间没有 happens-before，构成数据竞争。且该写发生在校验解析结果之前，一次失败的 Init 会把错误消息粒度模式永久改成实际未生效的值。 **修改内容** 针对缺陷 1（error_map_ 无锁读写）： - ParseJsonFormatString 内部改为持 mutex_ 后再改写 error_map_；相应地 Init(path) 不再自己持锁，锁下沉到真正操作 error_map_ 的位置，顺带把文件读取移出临界区，也避免了递归加锁； - ReportErrMessage 持锁查找并把 ErrorInfoConfig 整体拷贝出来，出锁之后只使用副本，不再把指向表内部的引用带出锁； - IsUserDefinedErrorCode 持锁读 error_map_。 针对缺陷 2（is_init_ 先检查后初始化不是原子操作）： - is_init_ 改为原子变量，读写使用 acquire/release 语义； - 新增 init_mutex_ 与 EnsureInitialized()，用双重检查加锁把 7 处懒初始化收敛到一处，各调用点原有的返回值语义保持不变；加锁顺序固定为 init_mutex_ 在前、mutex_ 在后。 针对缺陷 3（error_mode_ 在锁外写）： - error_mode_ 改为原子变量，读写使用 acquire/release 语义； - Init(mode) 改为配置解析成功之后才写入模式，解析失败不再污染模式。 ## 变更类型 - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue https://gitcode.com/cann/runtime/issues/842 ## 如何测试 ### 单元测试 tests/ut/error_manager/testcase/error_manager_unittest.cc 新增 3 个用例： 1. ConcurrentRegisterAndReportErrMessage —— 一个线程持续调用 RegisterFormatErrorMessage 注册新错误码触发 error_map_ 插入，另一线程并发调用 ReportErrMessage，校验并发写入过程中不丢失任何已注册模板。 2. InitWithModeNotPolluteModeOnFailure —— 校验 Init(mode) 在非法模式和配置解析失败两种场景下都不改写 error_mode_。 3. ConcurrentLazyInitFromMultipleThreads —— 未初始化状态下 8 线程并发上报，覆盖 is_init_ 先检查后初始化的竞争。 执行方式： bash tests/build_ut.sh -u error_manager 需要说明两点：用例 2 在普通构建下就能拦截回归，因为测试程序同级目录没有 conf/error_manager/error_code.json，Init 必然失败，修复前会因模式被污染而用例失败；用例 1 和用例 3 覆盖的是数据竞争，普通构建下不会让用例失败，需要开启 ThreadSanitizer 编译才具备检出能力。经实测，AddressSanitizer 对这两处竞争检不出来。 ### 端到端验证 三个缺陷各有一个独立用例，只调用对外接口，不依赖任何检测工具，修复前后结果对比明确。 **验证一（对应缺陷 1）：并发注册错误码不丢失、不崩溃** 并发注册在现网是真实存在的：注册宏依托静态变量初始化，动态加载算子包或插件时就会执行；注册接口还通过 runtime_keeper 传给了驱动，可能由驱动线程回调。因此"一个线程注册、另一个线程上报"并非构造出来的极端场景。 构造方法：4 个线程各注册 6 万个互不重复的错误码，全部结束后由单线程逐个上报，检查每个注册过的错误码都能查到。判定标准是查不到的数量为 0，且进程没有异常退出。 修复前：连续 8 轮，其中 7 轮出现错误码丢失（每轮丢 1 到 4 个），1 轮进程段错误退出。 修复后：连续 8 轮全部通过，无丢失、无崩溃。 规模会影响复现概率：注册总量 8000 时约一半轮次能复现，24 万时 8 轮全部复现。建议按 24 万规模、重复 3 轮以上执行。 **验证二（对应缺陷 2）：首次并发上报只解析一次配置文件** 构造方法：进程启动后先注册若干模板但不触发初始化，然后 N 个线程同时首次上报，各自触发懒初始化，测量这一批上报的总耗时。修复前每个线程都会完整解析一遍 error_code.json（实测文件 119 KB），耗时随线程数线性增长；修复后只解析一次，耗时与线程数无关。判定标准是耗时不随线程数增长。 同一台机器实测： | 线程数 | 修复前 | 修复后 | | --- | --- | --- | | 4 | 14 毫秒 | 4 毫秒 | | 8 | 28 毫秒 | 3 毫秒 | | 16 | 56 毫秒 | 3 毫秒 | | 32 | 111 毫秒 | 4 毫秒 | 修复前耗时正比于线程数，正是重复解析配置文件的直接证据；修复后稳定在 3 到 4 毫秒。 **验证三（对应缺陷 3）：初始化失败后，错误消息记录粒度不被改变** 构造方法：先正常上报一次错误，让错误管理器完成初始化；把动态库所在目录上一层的 conf/error_manager/error_code.json 临时改名，让配置解析失败；调用 ErrMgrInit 设置为进程粒度，确认返回失败；恢复文件；起两个线程各上报一条不同的错误码，各自取回错误消息。判定标准是每个线程只能看到自己上报的那条。 修复前：接口返回失败，但粒度已被改成进程级，两个线程共用同一个消息容器，一个线程取回了两条消息（包含另一个线程的报错，且带有进程粒度特有的线程号后缀），另一个线程取回为空。连续 5 次全部失败。 修复后：两个线程各取各的，互不干扰，连续 5 次全部通过。 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 已核对全部 12 个持 mutex_ 的函数，确认修改后不存在嵌套加锁；EnsureInitialized 的 init_mutex_ 与 mutex_ 加锁顺序单向，无死锁风险。 See merge request: cann/runtime!4364 | 15 天前 | |
feat: 添加error_manager_headers，支持多仓联编 Co-authored-by: Feiteng Zheng<zhengfeiteng1@h-partners.com> # message auto-generated for no-merge-commit merge: !1877 merge 20260428-add-error-manager-headers into master feat: 添加error_manager_headers，支持多仓联编 Created-by: zhengfeiteng Commit-by: Feiteng Zheng Merged-by: cann-robot Description: # Pull Request ## 描述 添加error_manager_headers，支持多仓联编。 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [x] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.对比修改前后二进制一致性。 ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/runtime!1877 | 4 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 个月前 | ||
| 21 天前 | ||
| 7 天前 | ||
| 15 天前 | ||
| 15 天前 | ||
| 4 个月前 |