已关闭
[issue] duplication top 模式同尺寸组取舍顺序未文档化 #15
cezarbbb创建于  9月9日关闭于  9月17日
cezarbbb
9月9日 创建
name about title labels
BotMetric 问题单 报告 BotMetric 中可复现的问题 [Issue] duplication top 模式 22 组等大重复取 20 时丢弃 pair_4/pair_14,取舍优先级未文档化 bug, duplication, low

问题概述

夹具 dup-many 含 22 组等大(11 行)重复块,duplication_findings = "top" + 默认 duplication_max_findings = 20 取 20 组时丢弃 pair_4(组哈希 fc99b7be…)与 pair_14(组哈希 fc56a6cd…),取舍优先级未在任何文档定义;结果确定(跨平台、跨版本一致)但规则不透明。首次出现版本:v1.1.0(duplication findings 为 v1.1.0 新功能)。受影响对象:启用重复发现的 Cargo 软件包/目录输入。实际影响:用户无法预判哪组被丢弃,审计场景可能遗漏关注组。本问题涉及发现条目取舍口径。

影响范围

项目 内容
分析对象 ☑ Cargo 软件包 ☑ 独立 .rs 文件(目录输入均适用)
受影响的指标、规则或报告字段 BM006 发现条目的 top 模式截断逻辑;配置键 duplication_findings / duplication_max_findings
影响程度 ☑ 轻微
临时规避办法 ① 调大 duplication_max_findings 覆盖全部组;② 改用 duplication_findings = "all";③ 等待文档定义取舍优先级

复现步骤

最小源码样例:夹具 fixtures\dup-many(48 个 .rs 文件、831 行,22 组 11 行重复块 + 1 组完全重复文件对)。自包含最小样例如下(3 组等大 11 行重复块 + max_findings=2,即可复现"同尺寸组截断取舍未文档化"现象;完整夹具 22 组下的 pair_4/pair_14 具体编号依赖该夹具,取舍规则本身同样未文档化。下述命令中的 <dup-ties> 即指向该样例目录):

dup-ties/
├── Cargo.toml
└── src/
    ├── lib.rs
    ├── g0.rs
    ├── g1.rs
    └── g2.rs

Cargo.toml:

[package]
name = "dup-ties"
version = "0.1.0"
edition = "2021"

src/lib.rs:

pub mod g0;
pub mod g1;
pub mod g2;

src/g0.rs(g1.rs / g2.rs 与其逐字节相同,构成 3 组等大 11 行重复块):

// g0.rs - identical 11-line block shared with g1.rs / g2.rs
pub fn tie_block(acc: u32) -> u32 {
    let mut acc = acc;
    acc += 10000;
    acc += 10001;
    acc += 10002;
    acc += 10003;
    acc += 10004;
    acc += 10005;
    acc += 10006;
    acc += 10007;
    acc += 10008;
    acc
}

src/g1.rs 与 src/g2.rs:内容与 src/g0.rs 完全相同(仅文件名不同)。

配置 bot-metric-dup-top-20.toml(关键项):

[thresholds]
duplication_max_findings = 20

[rules]
duplication_findings = "top"
  1. BM110 analyze <dup-many> --config bot-metric-dup-top-20.toml --format json → 20×BM006
  2. BM110 analyze <dup-many> --config bot-metric-dup-all.toml --format json(findings="all")→ 22×BM006
  3. 对比两组 finding 的组哈希,找出被丢弃的组
  4. x86 与 ARM64 各执行一次并对比

预期结果

文档定义同尺寸组的取舍优先级(如按哈希序/位置序),或输出中说明取舍规则,使用户可预判截断结果。

实际结果

top-20 丢弃 pair_4(fc99b7be…)与 pair_14(fc56a6cd…),取舍规则未文档化;结果确定,x86 与 ARM64 一致。证据:x86_linux\records\batch-05\;arm_linux\records-arm64\batch-09\verify-groupB_5-2_5-3_5-4.txt。

证据原文(x86_linux\records\batch-05\out\t55-many-top-20.json,共 2671 行,节选 findings 的 stable_subject 清单——20 组入选重复 + 2 条质量目标):

  "stable_subject": "quality-target:max_code_duplication_ratio",
  "stable_subject": "quality-target:max_file_duplication_ratio",
  "stable_subject": "duplicate:020495a78067cd83:14",
  "stable_subject": "duplicate:0fc7285907b6d4cb:14",
  "stable_subject": "duplicate:1c7f0d179e60b763:14",
  "stable_subject": "duplicate:2191ff92d38bb9d3:14",
  "stable_subject": "duplicate:239894a2fca9a27b:14",
  "stable_subject": "duplicate:6098f025d22d102b:14",
  "stable_subject": "duplicate:646f04eef676eb7b:14",
  "stable_subject": "duplicate:68140443a7b6d7db:14",
  "stable_subject": "duplicate:7129c49f7b2e5deb:14",
  "stable_subject": "duplicate:71693c57fe1fccd3:14",
  "stable_subject": "duplicate:75897d5fa349a5db:14",
  "stable_subject": "duplicate:990a7ab4f2277f23:14",
  "stable_subject": "duplicate:bd8f5a612bfa137b:14",
  "stable_subject": "duplicate:c5ad085feb7bdf13:14",
  "stable_subject": "duplicate:c773fea40b4b04ab:14",
  "stable_subject": "duplicate:c9ea0edf86947383:14",
  "stable_subject": "duplicate:db5c5d89377cea13:14",
  "stable_subject": "duplicate:e6b8082ac8c303ab:14",
  "stable_subject": "duplicate:eeb633027814197b:14",
  "stable_subject": "duplicate:f005875e1ae1866b:14",

……(节选,完整文件见 x86_linux\records\batch-05\out\t55-many-top-20.json;入选 20 组不含 fc99b7be(pair_4)与 fc56a6cd(pair_14))

证据原文(arm_linux\records-arm64\batch-09\verify-groupB_5-2_5-3_5-4.txt,5-4 部分):

=== 5-4 复现:top 模式同尺寸组取舍(22 组取 20 丢 pair_4/pair_14)===
命令:BM110 analyze fixtures/dup-many --config fixtures/configs/bot-metric-dup-top-20.toml --format json
      BM110 analyze fixtures/dup-many --config fixtures/configs/bot-metric-dup-top-23.toml --format json (全集对照)
BM006 数: 20 (22 组中入选 20)
入选组哈希前8: ['020495a7', '0fc72859', '1c7f0d17', '2191ff92', '239894a2', '6098f025', '646f04ee', '68140443', '7129c49f', '71693c57', '75897d5f', '990a7ab4', 'bd8f5a61', 'c5ad085f', 'c773fea4', 'c9ea0edf', 'db5c5d89', 'e6b8082a', 'eeb63302', 'f005875e']
被丢弃: fc99b7be → pair_4、fc56a6cd → pair_14(与 x86 观察项"丢 pair_4/pair_14"完全一致)
入选集合前 6 个哈希与 x86 归档逐字一致(dup-idx 内容哈希跨平台相同,第 17-20 位 x86 样板截断未列出,全集 22 哈希跨平台可对齐)。
结论:复现成立——top 模式 22 等大组取 20,丢弃 pair_4/pair_14,选择确定但非按大小/影响排序(文档未定义优先级)。

分析环境与范围

项目 内容
BotMetric 版本或提交号 v1.1.0(commit 8ef52f6)
操作系统与架构 x86_64 Linux(rustc/cargo 1.95.0)+ aarch64 Linux(rustc/cargo 1.98.0),均 root 用户
软件包 / 目标 / 特性 / 范围参数 dup-many(目录输入,默认 scope);--config bot-metric-dup-top-20.toml 与 bot-metric-dup-all.toml 对照
文件数 / 代码行数 48 个 .rs 文件 / 831 行
模块层级 / 重复窗口 11 行连续重复块 22 组(等大)+ 完全重复文件对 1 组

指标、发现与报告证据

  • ☑ 已说明发现条目的编号、严重级别、位置和 human_message:BM006 / warning / 各重复块位置(span 见证据文件)/ human_message 原文见证据文件
  • ☑ 已附 analysis-report:top-20 与 all 两份完整 JSON 存于 x86_linux\records\batch-05\
  • ☑ 指标口径:涉及重复发现取舍口径(top 模式同尺寸组截断规则未定义)
  • ☑ 已说明 Cargo/独立文件口径差异:不适用(目录与 Cargo 输入行为一致)

性能与资源证据

项目 内容
冷缓存 / 热缓存 冷缓存 x86 406ms / 热缓存 51ms;ARM64 热缓存约 0.05s
执行次数 / 基线 每平台 ≥2 次(原批次 + 批次 9 复现),结果稳定
总耗时 见上(dup-many 量级)
处理器占用 / 内存峰值 未采样(本项非性能问题)
采样工具 无
测试数据集规模 / 硬件条件 dup-many 48 文件 831 行;x86_64 与 aarch64 Linux 服务器(root)

附件与提交确认

  • ☑ 已检索现有问题单,确认不是重复问题
  • ☑ 已提供最小复现步骤、预期结果和实际结果
  • ☑ 已明确指标公式、统计范围和实际证据(如适用)——本条涉及重复发现取舍口径,已附组哈希证据
  • ☑ 已完成日志、配置、源码和附件脱敏(输出不含本机用户路径)
likedislike
WWangZijun成员
9月15日 关联了pull request:fix: preserve bounded machine output and ordering (issue#9_14_15)
WangZijun成员
9月15日 评论:

https://gitcode.com/xuanwu/bot-metric/merge_requests/8

结论:

  • 问题可复现:已通过修复前最小复现/回归测试确认。
  • 问题可修复:当前分支集成测试已验证修复行为。

具体修复:

  • 在输出预算检查前完成机器 JSON 序列化,避免 stdout 产生截断 JSON。
  • 区分输出预算超限与格式错误的 BM403 原因。
  • 明确 duplication top 模式的重复行数及 stable_subject 字典序取舍规则并增加测试。
likedislike
VVaynNecol成员
9月17日 关闭了 issue