[Bug-Report|缺陷反馈]: MurmurHash/CommonHash 完整块后的尾部字节读取错误-ops-nn-AtomGit

Closed

[Bug-Report|缺陷反馈]: MurmurHash/CommonHash 完整块后的尾部字节读取错误 #6976

yr923096443Add on 22 days agoClosed at 20 days ago

yr923096443

22 days ago Create

Describe the current behavior / 问题描述 (Mandatory / 必填)

为 PR #11393 补充缺陷跟踪与合入背景。

源码审查发现以下三份主机侧哈希实现存在尾部处理问题：

common/src/op_host/bank_mgr/hash.cpp：Ops::NN::HostTiling::MurmurHash
matmul/common/op_host/op_tiling/hash.cpp：Ops::NN::MurmurHash
common/src/op_host/bank_mgr/op_hash.cpp：RuntimeKb::CommonHash

触发条件：输入长度 len = 4n + r，其中 n >= 1，r 为 1、2 或 3。处理完整的 4 字节块后，key/ky 已向后推进，但旧代码仍从原始 src 读取尾部，导致实际尾部字节未参与哈希。CommonHash 还会把上一完整块保留在 tmp_ky 中，再左移并拼入尾部。

最小例子：字节序列 01 02 03 04 05 与 01 02 03 04 06，在相同 seed 和 len=5 下，旧版三份实现都得到相同哈希。

业务关联：这些函数用于主机侧 Tiling 缓存键或运行时知识库索引。常规缓存/知识库查询还会比较完整输入，但同一哈希只保留一个条目的路径会出现竞争、覆盖或无法命中。实际受影响范围取决于调用方传入的 key 长度；本 Issue 以函数级复现确认缺陷，未据此推断特定算子已发生错算。合入目的是恢复尾部参与哈希的语义，并用仓库内 UT 防止回归。

Environment Information / 环境信息 (Mandatory / 必填)

验证时间：2026-10-20。
主机：WSL / Kali Linux，x86_64，小端。
编译器：g++ (Debian 15.2.0-7) 15.2.0，C++17。
修复前源码：PR 基线 c54aa50；修复后源码：e218d160de34fe4ba18597f218b47bf895aecd8c。
昇腾硬件型号：本次为主机侧纯 C++ 函数复现，不依赖 NPU。
CANN SDK：本次独立复现未使用完整 SDK；编译仓库真实三份源码及头文件，仅对外部 log/log.h 提供无操作日志桩。
编译选项：-std=c++17 -Wall -Wextra -Werror -fsanitize=address,undefined -fno-omit-frame-pointer -fno-strict-aliasing。

Steps to reproduce the issue / 重现步骤 (Mandatory / 必填)

分别使用修复前 c54aa50 和修复后 e218d160 的三份真实实现；保持同一主机、相同输入和 seed。
使用对齐的 uint32_t 数组，避免把未对齐读取问题混入本次复现。在本次小端主机上，以下两组输入的前 5 字节分别为 01 02 03 04 05 和 01 02 03 04 06：

const std::array<uint32_t, 2> a = {0x04030201U, 0x00000005U};
const std::array<uint32_t, 2> b = {0x04030201U, 0x00000006U};
// 对以下每个函数分别调用 hash(a.data(), 5U, 271828U)
// 和 hash(b.data(), 5U, 271828U)，比较输出：
// Ops::NN::HostTiling::MurmurHash
// Ops::NN::MurmurHash
// RuntimeKb::CommonHash

对修复前后真实源码分别编译并运行，结果见下方日志。
另外对同一数组 a 检查长度 0、1、2、3、4、8；三份实现这些长度的修复前后结果均保持一致。
PR 已纳入三份实现的仓库 UT，进一步覆盖长度 0–16、四种 seed、默认 seed；两份 MurmurHash 的尾部使用不同字节 80 37 e9。

Describe the expected behavior / 预期结果 (Mandatory / 必填)

完整块之后的尾部必须从已推进的 key/ky 读取；本例中变化的第 5 字节应参与计算。
两份 MurmurHash 的结果应符合各自输入对应的 MurmurHash3_x86_32 向量。
CommonHash 使用自身的 HashCombine 语义，有尾部时先清零临时累加值，再组装实际尾部。
保留长度小于 4 以及长度为 4 的倍数（含 0）时的原有结果；CommonHash 无尾部时保留既有最后一次 HashCombine。
哈希仍可能存在正常的有限位宽碰撞；本修复消除的是忽略实际尾部造成的系统性碰撞。

2026-10-20 对真实源码重新编译运行的输出（A/B 为上述两组 5 字节输入）：

BEFORE c54aa50
HostTiling::MurmurHash len=5 seed=271828 A=0xf7b27165 B=0xf7b27165 equal=true
NN::MurmurHash len=5 seed=271828 A=0xf7b27165 B=0xf7b27165 equal=true
RuntimeKb::CommonHash len=5 seed=271828 A=0x39015787 B=0x39015787 equal=true

AFTER e218d160
HostTiling::MurmurHash len=5 seed=271828 A=0x409d4bb7 B=0xcaf46109 equal=false
NN::MurmurHash len=5 seed=271828 A=0x409d4bb7 B=0xcaf46109 equal=false
RuntimeKb::CommonHash len=5 seed=271828 A=0x347f5bfd B=0x347f5bfc equal=false

Compatibility: lengths 0,1,2,3,4,8 unchanged for all three implementations.

本次独立复现进程退出码为 0，ASan/UBSan 未报告错误。PR 页面当前显示全部 40 项流水线检查通过。完整 SDK 验证以 PR CI 记录为准。