一、问题描述（必填）

• 接口名：aclnnBitwiseAndTensorOut（aclnnInplaceBitwiseAndTensorOut 共享同一实现，同根因）
• 测试场景：multithread；压测日期：2026-11-14；执行卡号：1（Ascend 950PR / CANN 9.3.0）
• bug 判定：是bug（CANN 运行时并发竞态缺陷，最小独立复现已验证）

核心现象：多线程共享一个 aclrtContext 并发执行同一合法算子调用时，AICPU task 概率性异常，随后设备进入错误遏制态（后续所有 aclrtMalloc 连锁失败 507899）

二、问题复现步骤（必填）

最小独立复现程序（不依赖 fuzz 框架，附件 bc_thread_concurrency_repro.cpp，约 120 行）：

// N 个 std::thread 共享一个 aclrtContext，每线程独立 stream，循环执行：
//   创建 3 个小张量(INT16 [2,2], BROADCAST×2 + CONTINUOUS) → GWS → execute → sync → destroy
// 参数完全合法（BROADCAST 输入 md 标注 √，单线程 100% 通过）

1. 下载测试框架：https://gitcode.com/Alice_zhou/Vector_fuzz_cpp_testing/tree/main/turing_sec/aclnnAPI_fuzz/
2. 环境准备：将附件 bc_thread_concurrency_repro.cpp 编译（或直接使用 fuzz 框架附件 CPP）
3. 编译：g++ -std=c++11 -pthread bc_thread_concurrency_repro.cpp utils.cpp ... -lascendcl ...
4. 执行：./bc_thread 5 200（5 线程 × 200 迭代）

复现数据（同参数 INT16 BCAST+BCAST+CONT [2,2]，环境 Ascend 950PR / CANN 9.3.0）：

规律：失败概率随并发线程数和迭代次数递增；一旦触发，设备进入错误遏制态（后续 aclrtMalloc 连锁失败 507899 = OOM 错误码）；4-5 线程下几乎必定在 ~100 次总迭代内触发。

失败证据（plog）：

[ERROR] RUNTIME: [task_recycle_cqrpt_base.cc:94] PrintTaskErrorMsg:Task run failed, stream_id=144, pos=4,
  task_sn=31, sqe_type=5(aicpu_d), errType=0x1(task exception), sqSwStatus=0x20004
[ERROR] RUNTIME: [device_error_proc.cc:1270] ProcessStarsAicpuErrorInfo:
  The error from device(chipId:0, dieId:0), serial number is 50550,
  an exception occurred during AICPU execution, stream_id=144, errcode=2, msg:execute kernel inner error

三、附件与证据（必填）

• 复现附件（执行步骤说明 + 最小并发复现 CPP + fuzz CPP + plog + 执行日志 压缩件）：
  https://gitcode.com/Alice_zhou/issue/blob/main/artifacts/2026-11-14/aclnnBitwiseAndTensorOut_multithread.zip
• 测试框架复核（F1~F7）：通过
  • F1 索引有界：无索引类 tensor ✓
  • F2 数据值约束：INT16 常量 3/5 ✓
  • F3 shape 关系：BROADCAST 输入 md 标注 √，out=CONTINUOUS ✓
  • F4 kernel_name：错误在 AICPU 执行层（sqe_type=5），非算子 kernel ✓
  • F5 基线对照：单线程/2线程短运行 100% 通过 ✓
  • F6 同步语义：507018 已正确计入失败 ✓
  • F7 注入合法性：无注入，正常调用 ✓

💡 该问题由 fuzz 自动化压测平台发现，最小独立复现程序已验证（脱离框架仍复现），确认非测试框架缺陷而是 CANN 运行时层并发问题。

🔍 代码bug点定位（2026-11-14，结合独立最小复现验证）

测试框架复核（F1~F7）：通过（详见 issue 正文第三节）

独立最小复现验证：

• 编写脱离 fuzz 框架的 ~120 行 std::thread 并发测试程序（bc_thread_concurrency_repro.cpp）
• 复现成功：5线程×200迭代在第~47次总执行时AICPU task exception；4线程×200在第~49次
• 排除测试框架：单线程/2线程短运行100%通过，同参数同代码路径

代码排查：

• op_api 层（ops-math/math/bitwise_and/op_api/aclnn_bitwiseand.cpp）：CheckParams 正常，
  无并发相关问题
• kernel 层：INT16 BCAST+BCAST+CONT [2,2] 是最简单的元素级 AND，无复杂内存访问
• 失败点不在开源算子代码中——plog 显示错误位于 AICPU 任务调度层（sqe_type=5(aicpu_d)），
  即 runtime/driver 层

定位分析：

• 缺陷层级：CANN 运行时/driver 层（AICPU task scheduling），非算子层
• 触发条件：多线程共享一个 aclrtContext 并发执行小尺寸 AICPU 任务（高频 create/destroy +
  execute + sync 循环），概率性触发 sqSwStatus=0x20004 task exception
• 影响面：一旦触发，设备进入错误遏制态（后续所有 aclrtMalloc 连锁失败 507899），需 reset 恢复
• 疑点方向：共享 context 下的 AICPU 任务队列管理/流调度的竞态窗口；或 device memory allocator
  在高频并发 alloc/free 下的状态不一致
• 已排查范围：开源 op_api/kernel 无并发路径差异；最小复现确认非框架问题；确切根因需 CANN
  runtime/driver 团队分析（plog 中 task_sn=31, sqe_type=5 为 AICPU 任务，非 aiv/aic vector kernel）