| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
refactor: dflow session/compiler/executor 目录结构调整到 runner 平级目录 Co-authored-by: lining23666<lining.li@huawei.com> # message auto-generated for no-merge-commit merge: !4263 merge dflow into develop refactor: dflow session/compiler/executor 目录结构调整到 runner 平级目录 Created-by: lining23666 Commit-by: lining23666 Merged-by: cann-robot Description: ## 描述 将 dflow 的 session、compiler、executor 三个目录统一移入 dflow/runner/ 下，使 session 与 compiler、executor 处于平行层级。编译产物 libdflow_runner.so 输出到 dflow/runner/ 目录，目录结构与编译结果对应。 **调整前**： dflow/ ├── compiler/ ← 编译层（含 session 子目录） │ ├── CMakeLists.txt ← dflow_runner 编译定义 │ ├── data_flow_graph/ │ ├── model/ │ ├── pne/ │ └── session/ ← session 原在此 ├── executor/ ← 执行层 ├── deployer/ ├── ... **调整后**： dflow/ ├── runner/ ← 新建，dflow_runner 编译入口 │ ├── CMakeLists.txt ← dflow_runner 编译定义 │ ├── compiler/ ← 编译层 │ ├── executor/ ← 执行层 │ └── session/ ← session 层（与 compiler/executor 平级） ├── deployer/ ├── ... ## 变更类型 - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 ## 关联的Issue ## 如何测试 1. 增量编译 dflow_runner 目标，确认 libdflow_runner.so 输出到 dflow/runner/ 目录 2. 确认所有 #include 路径正确解析 3. 确认 pre-commit 检查全部通过 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 涉及 112 个文件变更（目录 rename + include 路径更新） - 编译验证通过：libdflow_runner.so 正确输出到 cmake-build-gcov/dflow/runner/libdflow_runner.so - 文档同步更新：docs/zh/design/modules/dflow/dflow.md、docs/en/design/modules/dflow/dflow.md、blacklist.txt See merge request: cann/ge!4263 | 1 个月前 | |
refactor: dflow session/compiler/executor 目录结构调整到 runner 平级目录 Co-authored-by: lining23666<lining.li@huawei.com> # message auto-generated for no-merge-commit merge: !4263 merge dflow into develop refactor: dflow session/compiler/executor 目录结构调整到 runner 平级目录 Created-by: lining23666 Commit-by: lining23666 Merged-by: cann-robot Description: ## 描述 将 dflow 的 session、compiler、executor 三个目录统一移入 dflow/runner/ 下，使 session 与 compiler、executor 处于平行层级。编译产物 libdflow_runner.so 输出到 dflow/runner/ 目录，目录结构与编译结果对应。 **调整前**： dflow/ ├── compiler/ ← 编译层（含 session 子目录） │ ├── CMakeLists.txt ← dflow_runner 编译定义 │ ├── data_flow_graph/ │ ├── model/ │ ├── pne/ │ └── session/ ← session 原在此 ├── executor/ ← 执行层 ├── deployer/ ├── ... **调整后**： dflow/ ├── runner/ ← 新建，dflow_runner 编译入口 │ ├── CMakeLists.txt ← dflow_runner 编译定义 │ ├── compiler/ ← 编译层 │ ├── executor/ ← 执行层 │ └── session/ ← session 层（与 compiler/executor 平级） ├── deployer/ ├── ... ## 变更类型 - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 ## 关联的Issue ## 如何测试 1. 增量编译 dflow_runner 目标，确认 libdflow_runner.so 输出到 dflow/runner/ 目录 2. 确认所有 #include 路径正确解析 3. 确认 pre-commit 检查全部通过 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 涉及 112 个文件变更（目录 rename + include 路径更新） - 编译验证通过：libdflow_runner.so 正确输出到 cmake-build-gcov/dflow/runner/libdflow_runner.so - 文档同步更新：docs/zh/design/modules/dflow/dflow.md、docs/en/design/modules/dflow/dflow.md、blacklist.txt See merge request: cann/ge!4263 | 1 个月前 | |
fix: dflow对aclInit重复初始化场景做兼容处理 Co-authored-by: lining23666<lining.li@huawei.com> # message auto-generated for no-merge-commit merge: !4441 merge fix/dflow-acl-repeat-init into develop fix: dflow对aclInit重复初始化场景做兼容处理 Created-by: lining23666 Commit-by: lining23666 Merged-by: cann-robot Description: # Pull Request ## 描述 dflow 两处 aclInit 调用（dflow_api.cc 的 DFlowInitialize 和 engine_daemon.cc 的 InitializeWithArgs）用进程内局部 acl_initialized flag 判断是否已初始化，存在两个问题： ### 问题1：重复初始化被误判为致命错误 当同进程其他组件已调过 aclInit() 时，dflow 重复调用会得到 ACL_ERROR_REPEAT_INITIALIZE(100002)，被 ret != ACL_SUCCESS 误判为致命错误返回 FAILED。按 ACL 文档定义，此返回码表示"重复初始化或重复加载"，ACL 已处于正确的已初始化状态，不应视为错误。 ### 问题2：重复初始化场景下误调用 aclFinalize aclInit 返回 ACL_ERROR_REPEAT_INITIALIZE 时表示外部已初始化 ACL，但 dflow 仍将 acl_initialized 置为 true，导致 DFlowFinalize/EngineDaemon::Finalize 时调用 aclFinalize 把外部初始化的 ACL 给 teardown 了。 ### 修复方案 1. **兼容重复初始化**：两处调用点将 ACL_ERROR_REPEAT_INITIALIZE 当成功处理（置 acl_initialized = true，继续执行），同时失败日志补充 acl 返回码便于定位 2. **正确管理 ACL 生命周期**：引入 acl_owned_by_dflow 标志区分 ACL 生命周期归属，仅当 dflow 自己 aclInit 成功（返回 ACL_SUCCESS）时才置 true，Finalize 时仅在该标志为 true 时才调用 aclFinalize | 场景 | aclInit 返回 | acl_owned_by_dflow | Finalize 时调 aclFinalize？ | |------|---------------|---------------------|-------------------------------| | dflow 自己初始化 | ACL_SUCCESS | true | 是 | | 外部已初始化 | ACL_ERROR_REPEAT_INITIALIZE | false | 否 | | 初始化失败 | 其他错误码 | false | 否 | ## 变更类型 - [x] 🐛 Bug 修复 ## 关联的Issue ## 如何测试 ### UT（ut_libge_helper_utest） 1. DFlowInitialize_acl_repeat_init：mock aclInit 返回 ACL_ERROR_REPEAT_INITIALIZE，断言 DFlowInitialize 返回 SUCCESS，且 DFlowFinalize 后不调用 aclFinalize 2. DFlowInitialize_acl_init_failed：mock aclInit 返回 ACL_ERROR_INVALID_PARAM，断言 DFlowInitialize 返回 FAILED，且不调用 aclFinalize 3. TestEngineDaemonAclRepeatInit：同上，针对 EngineDaemon::InitializeWithArgs 4. TestEngineDaemonAclInitFailed：同上，针对 EngineDaemon::InitializeWithArgs ### ST（helper_runtime_test） 1. DataFlowApiTest.DFlowInitialize_acl_repeat_init：同 UT 场景1 2. DataFlowApiTest.DFlowInitialize_acl_init_failed：同 UT 场景2 3. STEST_helper_runtime.TestEngineDaemonAclRepeatInit：同 UT 场景3 4. STEST_helper_runtime.TestEngineDaemonAclInitFailed：同 UT 场景4 ### 覆盖率 UT 和 ST 新增分支覆盖率均为 **100%**（4/4 分支），覆盖了 ACL_SUCCESS、ACL_ERROR_REPEAT_INITIALIZE、其他错误码三个路径。 ### 回归验证 - UT 28 个相关用例全部通过 - ST 8 个相关用例全部通过 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 无 See merge request: cann/ge!4441 | 1 个月前 | |
fix: LLT 使用 stub 避免真实 dump 依赖 Co-authored-by: yelongjian<yelongjian1@huawei.com> # message auto-generated for no-merge-commit merge: !4598 merge dev-llt0827 into develop fix: LLT 使用 stub 避免真实 dump 依赖 Created-by: yelongjian Commit-by: yelongjian Merged-by: cann-robot Description: # Pull Request ## 描述 fix:修复llt报错问题 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.NA ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!4598 | 28 天前 | |
fix: precommit整改 Co-authored-by: yelongjian<yelongjian1@huawei.com> # message auto-generated for no-merge-commit merge: !3726 merge dev-precommit into develop fix: precommit整改 Created-by: yelongjian Commit-by: yelongjian Merged-by: cann-robot Description: # Pull Request ## 描述 precommit整改 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.NA ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!3726 | 2 个月前 | |
refactor: dflow session/compiler/executor 目录结构调整到 runner 平级目录 Co-authored-by: lining23666<lining.li@huawei.com> # message auto-generated for no-merge-commit merge: !4263 merge dflow into develop refactor: dflow session/compiler/executor 目录结构调整到 runner 平级目录 Created-by: lining23666 Commit-by: lining23666 Merged-by: cann-robot Description: ## 描述 将 dflow 的 session、compiler、executor 三个目录统一移入 dflow/runner/ 下，使 session 与 compiler、executor 处于平行层级。编译产物 libdflow_runner.so 输出到 dflow/runner/ 目录，目录结构与编译结果对应。 **调整前**： dflow/ ├── compiler/ ← 编译层（含 session 子目录） │ ├── CMakeLists.txt ← dflow_runner 编译定义 │ ├── data_flow_graph/ │ ├── model/ │ ├── pne/ │ └── session/ ← session 原在此 ├── executor/ ← 执行层 ├── deployer/ ├── ... **调整后**： dflow/ ├── runner/ ← 新建，dflow_runner 编译入口 │ ├── CMakeLists.txt ← dflow_runner 编译定义 │ ├── compiler/ ← 编译层 │ ├── executor/ ← 执行层 │ └── session/ ← session 层（与 compiler/executor 平级） ├── deployer/ ├── ... ## 变更类型 - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 ## 关联的Issue ## 如何测试 1. 增量编译 dflow_runner 目标，确认 libdflow_runner.so 输出到 dflow/runner/ 目录 2. 确认所有 #include 路径正确解析 3. 确认 pre-commit 检查全部通过 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 涉及 112 个文件变更（目录 rename + include 路径更新） - 编译验证通过：libdflow_runner.so 正确输出到 cmake-build-gcov/dflow/runner/libdflow_runner.so - 文档同步更新：docs/zh/design/modules/dflow/dflow.md、docs/en/design/modules/dflow/dflow.md、blacklist.txt See merge request: cann/ge!4263 | 1 个月前 | |
fix: VerifyIpaddr使用精确IP匹配替代子串匹配，修复IP白名单绕过漏洞 Co-authored-by: lining23666<lining.li@huawei.com> # message auto-generated for no-merge-commit merge: !3754 merge fix/verify-ipaddr-exact-match into develop fix: VerifyIpaddr使用精确IP匹配替代子串匹配，修复IP白名单绕过漏洞 Created-by: lining23666 Commit-by: lining23666 Merged-by: cann-robot Description: # Pull Request ## 描述 修复 dflow deployer daemon 中 VerifyIpaddr 方法的 IP 白名单校验漏洞。 原实现使用 peer_uri.find(config.ipaddr) != std::string::npos 子串匹配，存在绕过风险： - 配置 192.168.1.1 时，192.168.1.100 也会匹配成功 - 配置 10.0.0.1 时，210.0.0.1 也会匹配成功 修复方案：复用已有的 DaemonClientManager::GetClientIpAndPort 方法从 peer_uri（格式 ipv4:ip:port）中精确提取 IP 地址，然后做精确字符串匹配。同时将 ClientAddr 和 GetClientIpAndPort 从 private 移为 public 以便复用。 ## 变更类型 - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue ## 如何测试 1. 配置远程节点 IP 白名单为 10.216.56.15 2. 从 10.216.56.15 发起连接，验证通过 3. 从 10.216.56.150 发起连接，验证被拒绝（旧代码会误放行） 4. 从 210.216.56.15 发起连接，验证被拒绝（旧代码会误放行） 5. 运行 UT TestVerifyIpaddrExactMatch 用例验证精确匹配和绕过场景 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效Commit的合并等 ## 其他信息 See merge request: cann/ge!3754 | 2 个月前 | |
fix: precommit整改 Co-authored-by: yelongjian<yelongjian1@huawei.com> # message auto-generated for no-merge-commit merge: !3726 merge dev-precommit into develop fix: precommit整改 Created-by: yelongjian Commit-by: yelongjian Merged-by: cann-robot Description: # Pull Request ## 描述 precommit整改 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.NA ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!3726 | 2 个月前 | |
fix: 修复ST中架构硬编码、失效用例与桩符号缺失导致的失败和超时 Co-authored-by: yelongjian<yelongjian1@huawei.com> # message auto-generated for no-merge-commit merge: !5111 merge fix/st-cases-arch-and-stub into develop fix: 修复ST中架构硬编码、失效用例与桩符号缺失导致的失败和超时 Created-by: yelongjian Commit-by: yelongjian Merged-by: cann-robot Description: # Pull Request ## 描述 修复 GE ST 中一批导致用例失败、ctest 超时和 ENGINES 编译失败的问题，全部改动限于测试脚本、测试桩与测试数据，**不涉及任何业务代码**。 ### 1. dflow ST 测试数据去掉架构硬编码 tests/dflow/runner/st/st_run_data/json/helper_runtime/ 下 4 个 numa_config*.json 的 node_def.resource_type 硬编码为 "X86"，覆盖了 config_parser.cc:131 中本就存在的架构感知默认值： cpp auto default_resource_type = ExecutionRuntime::IsX86() ? kResoureTypeX86 : kResoureTypeAarch; AssignOptionalField(node_def_config.resource_type, kConfigResourceType, j, default_resource_type); aarch64 上 FunctionCompile::CompileAllResourceType() 产出可运行资源类型 {Ascend, Aarch}，heavy_load UDF 经 DataFlowGraphAutoDeployer::SelectResourceType 选中 Aarch，而设备表里的 host CPU 资源类型是 JSON 写死的 X86，于是 HeterogeneousDeployPlanner::GetDeployEngineType 报 Failed to match device according to resource type[Aarch]，BuildGraph 返回失败，影响 4 个用例： - STEST_helper_runtime.TestDeployHeavyLoadUdfModelOnServer - STEST_helper_runtime.TestDeployHeavyLoadUdfModelOnServerWithHostFlowgw - STEST_helper_runtime.TestDeployHeavyLoadUdfModelOnDiffServerWithHostFlowgw - STEST_helper_runtime.TestDeployUdfModelsOnServerWithHostFlowgw 删掉该字段后由架构感知默认值接管：x86 上仍解析为 X86（行为完全不变），aarch64 上解析为 Aarch。 ### 2. STEST_helper_runtime::SetUpTestSuite 预置 release 包时同样硬编码了 X86 fixture 在 SetUpTestSuite() 里用 shell 预置 UDF release 包（因为 ProcessUtils::System 在 ST 中是空实现，UdfModelBuilder::PackRelease 不会真正产出 tar.gz），但 host 资源类型目录写死为 X86： bash mkdir -p ./temp_udf_st/build/_test/X86/release ... tar -cvf func_pp1_release.tar.gz func_pp1_release.om func_pp1_release.so 而 UdfModel::SerializeModel 读取的是 FunctionCompile 按架构产出的路径 —— aarch64 上是 _test/Aarch/release/func_pp1_release.tar.gz，预置的产物只在 _test/X86/ 和 _test/Ascend/ 下，于是报 Open file fail。 改为用 ExecutionRuntime::IsX86() 取架构并注入 shell 变量： cpp const std::string host_res_type = ExecutionRuntime::IsX86() ? "X86" : "Aarch"; std::string cmd = "HOST_RES=" + host_res_type + R"( ... mkdir -p ./temp_udf_st/build/_test/${HOST_RES}/release x86 上仍解析为 X86，行为完全不变。这与第 1 项是同一类架构硬编码问题，只是位置在测试 fixture 而非测试数据。 TestDeployHeavyLoadUdfModelOnDiffServerWithHostFlowgw 是该套件中唯一把 func_pp1 部署到远端 server 的用例，会经 FlowModelSender::TransferSubmodels 序列化子模型；其余 3 个 heavy_load 用例都在本地部署、不走该路径，所以只有它暴露此问题。 > 补充：曾尝试把 ProcessUtils::System 桩改为真实执行命令，但 dflow 大量用例会传入伪路径（./temp/build/_xxx/、_udf1、_udf2、temp_host_udf 等），干净工作区下 cp -fr 失败经 set -e 返回非 0，导致 ST 24 例、UT 14 例失败。故不改动共享桩，只修正 fixture 里的架构硬编码。 ### 3. cpueng ST 桩补齐缺失符号 host_engine_stest / cpu_engine_stest 链接失败： `` cpu_kernel_builder.cpp:766/768: undefined reference to aclrtGetDevice' / aclrtGetDeviceInfo' folding.cc:680/681: undefined reference to aicpu::CpuKernelContext::CpuKernelContext(aicpu::DeviceType)' aicpu::CpuKernelContext::Init(void*)' ` - stub/runtime/src/runtime_stub.cpp 增加 aclrtGetDevice / aclrtGetDeviceInfo，返回 ACL_ERROR_RT_FAILURE，使 CpuKernelBuilder::CalcBlockDimByShapeSize 走其既有的 kDefaultAicpuBlockDim 兜底分支（已确认 cpueng ST 无任何 block dim 断言） - stub/aicpu/aicpu_stub.cpp 增加 CpuKernelContext 构造函数与 Init(void*)，返回 0 以满足 folding_st.cpp:72 的 ASSERT_EQ(ret, 0) - stub/runtime/CMakeLists.txt 增加 ${ASCEND_INSTALL_PATH}/include 以取得 acl/acl_rt.h，写法沿用 tests/acl_ut/depends/acl/CMakeLists.txt ### 4. ffts ST 修复编译错误并清理失效用例 - fftsplus_dynamic_task_builder_stest.cc:24 删除死 include task_builder/mode/manual/manual_thread_task_builder.h（该路径已不存在，且全文件仅此一处提及 manual，无任何代码使用） - fftsplus_ops_kernel_builder_stest.cc:932-933 修正 nofity 拼写为 notify - 删除 12 个针对已移除派发层的失效用例：FFTSPlusOpsKernelBuilder::GenerateTask 现仅处理带 ATTR_NAME_ALIAS_ENGINE_NAME 的 MIXL2 节点，其余分支为带 FFTS_LOGE 的显式 return FAILED；TheadTaskBuilder 仅剩 Mixl2ModeTaskBuilder 一个子类，task_builder/mode/manual/ 已整体删除。被删用例覆盖的入口已不存在，不可能通过。反证：全文件仅 2 处设置该属性（MIX_L2_GenerateTask_SUCCESS、tiling_sink_gentask_for_ffts），这两个用例均通过。 被删用例清单：GenerateTask_SUCCESS、GenerateTask_Greater60_Schecule_SUCCESS、GenerateTask_Greater60_SUCCESS、Mix_GenerateTask_SUCCESS、Auto_RTSOP_GenerateTask_SUCCESS、AICPU_GenerateTask_Schecule_Failed、AICPU_GenerateTask_SUCCESS、HCCL_GenerateTask_SUCCESS、RTSOP_GenerateTask_IF_SETIF、RTSOP_GenerateTask_CASE_SETIF、RTSOP_GenerateTask_While_SETIF、RTSOP_GenerateTask_If_If_SETIF。 > 注：其中两处 tasks[0] 在 tasks 为空时的越界访问（曾导致整个 ffts_st 二进制 core dump、后续 41 个用例无法执行）随所属用例一并移除。 ## 变更类型 - [x] 🐛 Bug 修复 - [ ] ✨ 新功能 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无。与 #5072 相关：本 PR 修复的 slice_result_mocker static 状态泄漏，是在 #5072 去掉 libasan 预加载后才暴露出来的既有缺陷。 ## 如何测试 前提：aarch64 + CANN 9.3.0 + conda baize_py39，ASAN 关闭（ENABLE_ASAN=false）。 1. 全量 ST 端到端： bash bash tests/run_test.sh --st 预期 rc=0 并完整打印 test end:，耗时约 13m30s。 2. 单独复验 dflow（含原 4 个失败用例）： bash bash tests/run_test.sh --st=dflow 预期 helper_runtime_test 183/183 通过、ctest 100% tests passed, 0 tests failed out of 2，且日志中 Failed to match device according to resource type[Aarch] 与 Open file fail 均为 0 次。 3. 单独复验受影响的 ENGINES： bash bash tests/run_test.sh --st=aicpu # 预期 12/12 + 77/77 + 82/82 全通过，无 undefined reference bash tests/run_test.sh --st=ffts # 预期 88/88 全通过，无 core dump 4. 单独复验 jit_execution： bash bash tests/run_test.sh --st=hetero 预期 ut_jit_execution_st 125/125 通过、ctest 100% tests passed, 0 tests failed out of 8。 ### 实测结果 | 项目 | 修复前 | 修复后 | |------|--------|--------| | bash tests/run_test.sh --st | 100 分钟跑不完，从未打印 test end: | rc=0，test end: 正常，13m30s | | gtest 用例 | — | 3258 个，**0 失败**，13 跳过 | | ctest st_hetero / st_dflow / fe | dflow Timeout | 8/8、2/2、4/4 全部 100% | | helper_runtime_test | Timeout 1500s（183 例只跑完 117） | Passed 64s，183/183 | | st_fast_runtime2_test | 2336s | 33s | | ge_common_atc（phase2） | 702/702 | 702/702 | | ENGINES aicpu | 链接失败 | 171/171 | | ENGINES ffts | 编译失败 | 88/88 | | ENGINES dvpp / tefusion | 26/26、263/263 | 26/26、263/263 | | Segmentation fault / AIR build failed / ST FAILED | 有 | 均为 0 | ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 全部改动位于 tests/ 下，**不含任何业务代码改动**；git diff --name-only 过滤 ^tests/ 后为空。 - 本地 pre-commit 全部 Passed（trim trailing whitespace、fix end of files、check for added large files、check for merge conflicts、detect private key、clang-format、codespell、OAT Compliance Check）；推送时远端 Git Hooks Checking 亦为 PASSED。 - 第 1 项在 x86 上为行为等价的 no-op（IsX86() 为 true 时默认值即 X86`，与原硬编码相同），仅在 aarch64 上生效。 - 第 5 项删除的 12 个用例对应已移除的派发层，建议 ffts 模块 owner 确认该精简为有意设计而非回归。 See merge request: cann/ge!5111 | 2 天前 | |
refactor: dflow session/compiler/executor 目录结构调整到 runner 平级目录 Co-authored-by: lining23666<lining.li@huawei.com> # message auto-generated for no-merge-commit merge: !4263 merge dflow into develop refactor: dflow session/compiler/executor 目录结构调整到 runner 平级目录 Created-by: lining23666 Commit-by: lining23666 Merged-by: cann-robot Description: ## 描述 将 dflow 的 session、compiler、executor 三个目录统一移入 dflow/runner/ 下，使 session 与 compiler、executor 处于平行层级。编译产物 libdflow_runner.so 输出到 dflow/runner/ 目录，目录结构与编译结果对应。 **调整前**： dflow/ ├── compiler/ ← 编译层（含 session 子目录） │ ├── CMakeLists.txt ← dflow_runner 编译定义 │ ├── data_flow_graph/ │ ├── model/ │ ├── pne/ │ └── session/ ← session 原在此 ├── executor/ ← 执行层 ├── deployer/ ├── ... **调整后**： dflow/ ├── runner/ ← 新建，dflow_runner 编译入口 │ ├── CMakeLists.txt ← dflow_runner 编译定义 │ ├── compiler/ ← 编译层 │ ├── executor/ ← 执行层 │ └── session/ ← session 层（与 compiler/executor 平级） ├── deployer/ ├── ... ## 变更类型 - [x] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [x] 📦 构建过程或辅助工具的变动 ## 关联的Issue ## 如何测试 1. 增量编译 dflow_runner 目标，确认 libdflow_runner.so 输出到 dflow/runner/ 目录 2. 确认所有 #include 路径正确解析 3. 确认 pre-commit 检查全部通过 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 - 涉及 112 个文件变更（目录 rename + include 路径更新） - 编译验证通过：libdflow_runner.so 正确输出到 cmake-build-gcov/dflow/runner/libdflow_runner.so - 文档同步更新：docs/zh/design/modules/dflow/dflow.md、docs/en/design/modules/dflow/dflow.md、blacklist.txt See merge request: cann/ge!4263 | 1 个月前 | |
fix: 统一管理 Python 解释器生命周期 Co-authored-by: du-hua1024<duhua2@huawei.com> # message auto-generated for no-merge-commit merge: !3631 merge develop into develop fix: 统一管理 Python 解释器生命周期 Created-by: du-hua1024 Commit-by: du-hua1024 Merged-by: cann-robot Description: # Pull Request ## 描述 当前 TBE、Python Pass 等多处依赖 Python 解释器，本 PR 引入 GePythonRuntimeManager，在 GE 各初始化入口统一探测、加载 libpython 并管理 Python 解释器生命周期，为 Python Fusion Pass 等能力提供一致的运行时基础。 **主要变更：** ### 1. 新增 GePythonRuntimeManager（base/common/python_runtime/） - ge_python_runtime_manager.h：管理器类定义，提供 EnsureReady() / ShutdownProcess() 接口 - ge_python_runtime_manager.cc：管理器实现，包含 EnsureReadyLocked()、FinalizeOwnedInterpreterLocked() 等核心逻辑 - ge_python_runtime_manager_helper.h：辅助头文件，包含 Python C API 类型定义、符号常量、探测脚本及 inline 工具函数（ResolvePythonCApi、EnsureLibpythonLoaded、ProbePythonRuntimeFromCommand 等） - 自动探测 python3/python 并解析 libpython 路径，通过 dlopen 加载 Python C API - 若进程内已有解释器则 attach，否则初始化 owned interpreter 并在 init 线程释放 GIL ### 2. 接入 GE 初始化链路 - GEInitializeV2 / GEFinalizeV2（api/session/client/ge_api_v2.cc） - GeGenerator::Initialize（compiler/api/generator/ge_generator.cc） - aclgrphBuildInitializeImpl / aclgrphBuildFinalize（compiler/api/aclgrph/ge_ir_build.cc） - ATC 离线编译路径（api/atc/main_impl.cc）：GenerateModel、GenerateSingleOp 等入口在 GELib::Initialize 前调用 EnsureReady()，失败/退出路径补充 ShutdownProcess() ### 3. 测试更新 - 新增 ge_python_runtime_unittest.cc，覆盖 attach 已有解释器、owned interpreter 初始化与 shutdown 场景 - 更新 fusion_pass_executor_unittest.cc：添加 python_pass_loaded_ 状态追踪，SetUp/TearDown 仅在加载过 Python pass 时调用 UnloadPythonPasses() - 更新 ge_generator_unittest.cc、ge_api_v2_unittest.cc、ge_ir_build_unittest.cc 等，在 teardown 中调用 ShutdownProcess() 避免用例间状态污染 - 更新 ST 测试入口（test_main.cc、rt2_test_main.cc、dump_test_fixture.h）添加 ShutdownProcess() - 更新 dflow 测试（test.cc、init_ge.h、dflow_api_unittest.cc、ge_api_dflow_unittest.cc）添加 GEFinalize() 调用 - 新增 scoped_unset_ld_preload.h 辅助类，用于 ge_running_env_test 中临时清除 LD_PRELOAD 环境变量 ## 变更类型 - [x] ✨ 新功能 - [ ] 🐛 Bug 修复 - [ ] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue 无 ## 如何测试 1. 验证在线、离线、atc 场景编译入口在加载 Python pass 前能成功初始化解释器（日志含 [GePythonRuntime] Loaded libpython 或 Initialize owned interpreter） 2. 运行 ge_python_runtime_unittest 验证 attach/owned interpreter 生命周期管理 3. 运行 fusion_pass_executor_unittest 验证 Python pass 注册与卸载逻辑 ## 核对清单 - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如：feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于 commit message 的格式、无效 commit 的合并等 ## 其他信息 无 See merge request: cann/ge!3631 | 2 个月前 | |
fix: precommit整改 Co-authored-by: yelongjian<yelongjian1@huawei.com> # message auto-generated for no-merge-commit merge: !3726 merge dev-precommit into develop fix: precommit整改 Created-by: yelongjian Commit-by: yelongjian Merged-by: cann-robot Description: # Pull Request ## 描述 precommit整改 ## 变更类型 请选择本次引入的变更类型： <!-- [x] 表示选中 --> - [ ] 🐛 Bug 修复 - [ ] ✨ 新功能 - [x] 💄 代码风格更新（格式化，局部变量） - [ ] ♻️ 重构（既不修复错误也不增加功能的代码变动） - [ ] 📦 构建过程或辅助工具的变动 - [ ] 📝 文档内容更新 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在当前页面的右侧'关联Issue'部分添加相应Issue链接，并勾选'合并后关闭已关联的 Issue'选项。 --> ## 如何测试 描述测试此变更的步骤和前提条件： 1.NA ## 核对清单 <!-- [x] 表示选中 --> - [x] 我的代码遵循了项目的代码风格 - [x] 我已对代码进行了自测 - [x] 我已更新了相关的文档 - [x] 我在标题中使用了合适的类型标签（如： feat:, fix:） - [x] 我已经详细阅读了贡献指南（CONTRIBUTING.md），并遵守了其中的所有规定，包括但不限于commit message的格式、无效commit的合并等 ## 其他信息 在此添加任何其他关于本次 PR 的说明。 See merge request: cann/ge!3726 | 2 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 28 天前 | ||
| 2 个月前 | ||
| 1 个月前 | ||
| 2 个月前 | ||
| 2 个月前 | ||
| 2 天前 | ||
| 1 个月前 | ||
| 2 个月前 | ||
| 2 个月前 |