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 中本就存在的架构感知默认值：

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：

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 变量：

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 个用例无法执行）随所属用例一并移除。

变更类型

• 🐛 Bug 修复
• ✨ 新功能
• 💄 代码风格更新（格式化，局部变量）
• ♻️ 重构（既不修复错误也不增加功能的代码变动）
• 📦 构建过程或辅助工具的变动
• 📝 文档内容更新

关联的Issue

无。与 #5072 相关：本 PR 修复的 slice_result_mocker static 状态泄漏，是在 #5072 去掉 libasan 预加载后才暴露出来的既有缺陷。

如何测试

前提：aarch64 + CANN 9.3.0 + conda baize_py39，ASAN 关闭（ENABLE_ASAN=false）。

1. 全量 ST 端到端：

   bash tests/run_test.sh --st
   

   预期 rc=0 并完整打印 test end:，耗时约 13m30s。

2. 单独复验 dflow（含原 4 个失败用例）：

   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 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 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

核对清单

• 我的代码遵循了项目的代码风格
• 我已对代码进行了自测
• 我已更新了相关的文档
• 我在标题中使用了合适的类型标签（如：feat:, fix:）
• 我已经详细阅读了贡献指南（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 确认该精简为有意设计而非回归。