# PPT 补充数据 · Q6（7 项，按重要性）

> 实验机 `ubuntu@cuda-ke`。下载站 http://down.kew.ac/ 。
> **7 项全部定稿并含实测数值。** 数据文件:`Q6_ablation.csv`、`Q6_freetype2_300s.csv`、`Q6_sqlite_var.csv`。
>
> **⚠️ 最重要一条**:#1 干净消融把旗舰 **+3.18pp 打回 ≈0pp**（固定 T=30 多轮后基线=全增强)——deck 需据此改。

---

## #1 · 干净消融：同超时 T=30 下分离"超时延长" vs "算法净贡献"〔最重要〕✅

**问题定性（已查实，`Work_Progress_Report_3.md:215–225`）:**
- 旗舰数 **+3.18pp** = libarchive 的 **FstatsCov 差值之差**：全增强 (+4.56pp) − 基线 (+1.38pp)。
- **污染来源**：基线用 `SYMCC_TIMEOUT=10`，全增强用 `SYMCC_TIMEOUT=30`——**两组每输入求解预算不同**，
  +3.18pp 里混入了"多给 20s 求解"的收益。报告自己也标了这个缺陷(`WPR3:225`:"无法排除覆盖率差异中
  有多少来自超时增加本身")。
- **更糟**：优化④(选择性符号化)因 `symcc_interesting=0` **实际未激活**(`PPT_Material.md:509`),
  所以 +3.18pp 实为 **①②③ + 超时增加**,而非 ①②③④。
- **注意方向**：污染是"基线 T=10、全增强 T=30"（基线更短，不是题面说的"基线 T=30 全增强更长"）。

**干净实验设计（固定 T=30，去污染）:** libarchive、np=32、300s、hybrid、多轮。三臂:
| 臂 | 配置 | 目的 |
|---|---|---|
| B@T10 | `MULTI_SOLVE=0 FAST_SOLVE=0 EMIT_HINTS=0 TIMEOUT=10` | 近似原基线 |
| B@T30 | 同上但 `TIMEOUT=30` | 基线只把超时抬到 30 |
| F@T30 | `MULTI_SOLVE=1 FAST_SOLVE=1 EMIT_HINTS=1 TIMEOUT=30` | 全增强 |

- **干净 delta（算法净贡献，超时固定 30）= F@T30 − B@T30**
- **超时贡献 = B@T30 − B@T10**（这就是要从 +3.18pp 里剔除的部分）
- 每臂同时给 Hybrid ShowmapCov（`edge_cov_pct`）与 AFL-only FstatsCov（`afl_bitmap_cvg`），
  确认 AFL 基线在三臂间稳定→Hybrid 差异可归因于 SymCC 增强。

> **代码约束（诚实说明）**：②智能调度是代码级、③hint 原本硬编码为常开。本轮已把 `mpi_fuzzing_helper.py:576`
> 改成 `env["SYMCC_EMIT_HINTS"]=os.environ.get("SYMCC_EMIT_HINTS","1")`（默认仍开，可被 env 关闭），
> 故 ③ 可消融；②(调度策略)无法用 env 干净关闭，两臂都在→其独立贡献不在本 delta 内(留作代码级消融)。
> 因此本 delta 精确度量的是 **①(多分支联合求解)+③(hint)+⑤(fast-solve) 在固定 T=30 下的净贡献**。

**实测结果（libarchive，np=32，300s，各跑满 ~304s）:**

| 臂 | Hybrid ShowmapCov（每轮） | 均值±σ | AFL-only FstatsCov | MPI-only cov | MPI tc/s |
|---|---|---|---|---|---|
| **B@T10** | 35.42 / 29.62 | **32.5 ±2.9**(n=2) | 26.9% | 10.48% | 490 |
| **B@T30** | 27.21 / 26.70 | **26.95 ±0.26**(n=2) | 24.6% | 11.00% | 498 |
| **F@T30** | 26.74 / 26.76 / 27.36 | **26.95 ±0.29**(n=3) | 24.0% | 11.00% | **5,856** |

**干净 delta（超时固定 T=30）= F@T30 − B@T30 = 26.95 − 26.95 = 【≈ 0.00 pp】。**

- **旗舰 +3.18pp 不成立**：把超时固定在 30 并多跑几轮后,全增强与基线的 libarchive Hybrid 覆盖率**完全持平
  (都是 26.95%,σ≈0.3pp)**——算法①③⑤的净覆盖贡献 ≈ 0。原 +3.18pp 主要来自 **T=10→30 的超时变化 +
  单轮噪声**,不是算法。
- **超时方向也不成立**：B@T10(32.5) > B@T30(26.95),即"更短超时反而更高"——但 B@T10 是 n=2、σ=2.9 的
  强噪声(有个 35.42 离群),不可靠;照面值看,**超时增加不但没帮忙甚至更低**,进一步说明 +3.18pp 是噪声+混淆。
- **增强真正可测的效果是"生成量"不是"覆盖"**：全增强让 SymCC 生成速率涨 **~12×**（MPI tc/s 498→5,856,
  主要来自 ⑤fast-solve),但这些多出来的用例**没转化成 libarchive 覆盖**(MPI-only cov 都是 11.00%)——
  因为 libarchive 卡点是格式分发(AFL 已处理),不是"求解更多/更快"。

**给答辩的结论**：*"去掉超时污染、固定 T=30 并多轮后,libarchive 上增强的净覆盖贡献 ≈ 0pp(26.95% vs 26.95%);
原单轮 +3.18pp 由超时变化与噪声主导。增强的可测效果是求解吞吐 ~12× 提升,但在 libarchive 上不转化为覆盖。"*
→ **建议 deck 不再把 +3.18pp 当作"算法有效"的旗舰证据**。

**诚实caveat**：② 智能调度是代码级、两臂都开(未隔离其独立贡献);baseline 臂 n=2 偏薄;结论是 libarchive
专属——增强或对约束密集目标(如 sqlite+字典)有效,那是另一回事,不支撑当前这个 libarchive 旗舰主张。
数据文件 `Q6_ablation.csv`。

---

## #2 · freetype2 300s np=8/np=32 三轮〔让 P115 与 §3.6(D4 更正)一致〕✅

D4 已在 **120s·adaptive** 下证明 np8≈np32("腰斩"不成立)。本项在 **300s·非自适应 hybrid**(与 P115 主表口径
一致)复测 3 轮:

| np | Hybrid ShowmapCov（每轮） | 均值±σ |
|---|---|---|
| **8** | 12.87 / 15.88 / 15.49 | **14.75 ±1.34** |
| **32** | 15.32 / 14.55 / 13.57 | **14.48 ±0.72** |

- **np=8 ≈ np=32(14.75 vs 14.48,差 0.27pp 远在 σ 内)——在 300s 头条口径下再次证明"腰斩"不成立。**
- 两者都 ~14–15%(比 120s 的 ~12–13% 高,更多时间→更高,合理);**原 np=32 = 5.59% 是离群单轮,已彻底否定**。

→ **P115 改法**：freetype2 两格从 `11.23%(np8) / 5.59%(np32)` 换成 `14.8%±1.3(np8) / 14.5%±0.7(np32)`
(300s,n=3),并去掉"np=32 覆盖腰斩/拥塞"的论断,与 §3.6 一致。数据文件 `Q6_freetype2_300s.csv`。

---

## #3 · 主结果多轮方差〔支撑 P108/P148 显著性，去掉"14×σ"式过强表述〕✅

**问题定性（已查实）:**
- 全部头条结果为 **单轮 rounds=1**（`Final_Work_Report.md:5` 自述"未计算标准差"）。
- "14×σ" 是**隐式**说法：`PPT_Material.md:507`"libarchive +3.18pp…远超基线波动(±0.23pp),统计可信"
  → 3.18/0.23 = **13.8 ≈ 14σ**。但这是**指标错配**：分子是单轮 FstatsCov 差值之差,分母 ±0.23pp 是
  **AFL-only ShowmapCov** 在 6 次运行的 std(不同指标),而且那 6 次是深度集成实验的 AFL 臂,非专门重复。
- 唯一真多轮数据是 `Research_and_Optimization_Report.md:402`(np=64 分配研究,rounds=2)。

**实测真实 σ（300s，Hybrid ShowmapCov）:**

| 目标 | 配置 | 每轮 | 均值±σ |
|---|---|---|---|
| libarchive | np=32 全增强 | 26.74 / 26.76 / 27.36 | **26.95 ±0.29**(n=3) |
| libarchive | np=32 基线 | 27.21 / 26.70 | 26.95 ±0.26(n=2) |
| libarchive | np=32 基线@T10 | 35.42 / 29.62 | 32.5 **±2.9**(n=2,示例:σ 可以很大) |
| freetype2 | np=8 | 12.87 / 15.88 / 15.49 | **14.75 ±1.34** |
| freetype2 | np=32 | 15.32 / 14.55 / 13.57 | **14.48 ±0.72** |
| sqlite | np=32 | 29.48 / 31.46 / 30.62 | **30.52 ±0.81** |

**"14×σ" 判决:** 该主张 = `+3.18pp ÷ ±0.23pp = 13.8σ`。**已被 #1 直接推翻**——分子 +3.18pp 在固定 T=30 多轮后
**变成 ≈0pp**;而真实 σ 实测 **0.3–1.3pp**(个别配置甚至 2.9pp)。所以 0 / (0.3~1.3) = **0σ,不是 14σ**。

**改表述建议(照此)**：
- **删掉**"+3.18pp 远超基线波动(±0.23pp),统计可信"这类"~14σ"表述(指标错配 + 单轮 + 已被多轮否定)。
- 头条覆盖率统一报 **"n=3 均值 ± σ"**;凡 **差异 < ~1–2pp** 一律标 **"在方差内 / 需更多轮确认"**,不下"显著优于"的结论。
- σ 本身**因目标/配置而异**(libarchive 全增强 0.3pp,但 baseline@T10 达 2.9pp;freetype2 ~1pp)——不要用单一
  ±0.23pp 去套所有结论。

**sqlite 附注**：原 deck 的"SQLite +0.96pp(±0.63pp),需多轮确认"——本轮实测 σ=**0.81pp**,与其 ±0.63 同量级;
`+0.96pp / 0.81 ≈ 1.2σ`,**确属"在方差内、不显著"**,deck 那句诚实 caveat 是对的,保留即可(别升级成"有效")。

数据文件 `Q6_ablation.csv` / `Q6_freetype2_300s.csv` / `Q6_sqlite_var.csv`。

---

## #4 · PCGUARD 边编码确认〔统一 P92–105 碰撞/分母口径〕✅ 已定稿

**结论：你的 `-afl` 二进制是 AFL++ `LLVM-PCGUARD`（afl-cc++4.40c），采用【每边唯一 guard 直接索引】的
【无碰撞】边覆盖，NOT `(prev>>1)⊕cur`，NOT 64KB hash 图。**

实证（`google-fts-afl/xml_read_fuzzer` 反汇编 + 受控编译，均在实验机）:

1. **增量指令 = 直接索引**（`main` 入口块 `0x16820`）:
   ```asm
   mov    (__afl_area_ptr),%r12          ; map 基址
   movslq (__start___sancov_guards+off),%rax  ; rax = *guard（该块唯一 index）
   movzbl (%r12,%rax,1),%ecx             ; ecx = map[*guard]   ← 直接用 guard 值索引
   inc %cl ; …饱和… ; mov %dl,(%r12,%rax,1) ; map[*guard]++
   ```
   **全二进制 `%fs`-XOR 站点 = 0，`__afl_prev_loc` 不参与增量**——即**没有** `(prev>>1)⊕cur` 那步异或。
2. **无碰撞、分母=guard 数**：`__sancov_guards` 段 = 203,460 B = **50,865 个 guard**;afl-showmap 报的
   `out of 50880`(向上取整 64 = 795×64)。**分母是本目标真实 guard 数,不是 65536**;每 guard 唯一槽→**零碰撞**。
3. **是"边"不是"块"**：编译器 banner 显示 `mode: LLVM-PCGUARD`(用 `SanitizerCoveragePCGUARD.so`);
   受控程序(3 个 if)产出 **8 个 guard > 源基本块数** → 该 pass **拆分了关键边(critical-edge splitting)**,
   每条 CFG 边分到一个唯一 guard。所以 afl-showmap 的 "tuples/edges" = 无碰撞的**边**槽。

**P92–105 统一口径（照此写）:**
- 覆盖率 = 命中边 guard 数 / **本目标 guard 数**(如 gfts-xml = 50,880),**不是 /65536**。
- **无 hash 碰撞**(PCGUARD 每边唯一 index),故**不需要**"碰撞修正/64KB 图"的讨论——那是**经典 AFL**
  `(prev>>1)⊕cur` 的事,与我们的 PCGUARD 二进制无关。
- ⚠️ **勘误**：此前 D2 页写的"guard 命中 + AFL `prev>>1 ^ cur` 边编码"**不准确**,已改为上面的
  "每边唯一 guard 直接索引(无碰撞)";图 `img_d2_pcguard.png` 的 objdump 证据仍有效(证明每块一个 guard)。

---

## #5 · np=64 补进吞吐曲线 + 10 目标完整结果表〔P111 图 / §3 结果〕✅ 已定稿

**(a) np=64 补点**（xml_read_fuzzer，MPI-only；原 scaling 表缺 np=64，已由 D1 补测）:

| np | serial | 2 | 8 | 32 | **64（新）** | 128 | 190 |
|---:|---:|---:|---:|---:|---:|---:|---:|
| tc/s | 0 | 128 | 1,604 | 7,579 | **16,881** | 14,917 | 13,813 |
| ShowmapCov | 3.09% | 5.69% | 5.88% | 6.21% | **6.75%** | 6.25% | 6.05% |

→ **np=64 是吞吐与覆盖【双峰】**：32→64 超线性(2.2×),且 **64 同时超过 128 和 190**;曲线在 64 之后回落。
把这一点画进 P111,曲线才不是"单调上升到 128",而是**峰在 64 的倒 U**。
(np=64 数据来自 D1 复测:16,881 tc/s / 6.75% / 3432 of 50880;与 scaling 表相邻点一致。)

**(b) 10 目标完整 ShowmapCov 表**（`Final_Work_Report.md:206–217`，300s，单轮；freetype2 一格由 #2 多轮更新）:

| 目标 | AFL总边 | 种子 | MPI best (np) | AFL-only | **Hybrid best (np)** |
|---|---:|---:|---:|---:|---:|
| png | 3,072 | 10.35% | 14.94% (2) | 14.10% | **16.96% (32)** |
| xml | 50,880 | 3.08% | 5.74% (2) | 7.60% | **8.90% (32)** |
| base64 | 1,088 | 11.58% | 23.25% (8) | 7.81% | **23.90% (8)** |
| md5sum | 1,344 | 7.14% | 7.14% (–) | 7.37% | 7.37% (–) |
| uniq | 1,216 | 9.54% | 9.54% (–) | 10.61% | 10.61% (–) |
| who | 10,688 | 6.73% | 6.73% (–) | 44.57% | **47.26% (32)** |
| libarchive | 13,760 | 6.45% | 13.90% (8) | 15.07% | **23.36% (32)** |
| SQLite | 31,680 | 13.70% | 14.97% (2) | 18.55% | **18.84% (32)** |
| pcre2 | 7,488 | 7.16% | 18.66% (8) | 41.73% | **43.58% (32)** |
| freetype2 | 21,632 | 2.22% | 2.26% (2) | 5.75% | 11.23% (8) →#2更新 |

> **口径提醒**：tc/s 吞吐表(P11)目前只覆盖 3 个目标(xml/SQLite/base64);上表是 10 目标的**覆盖率**。
> 没有"10 目标 × (覆盖率+tc/s)"的单一大表——如需,可再补齐其余 7 个目标的 tc/s(单轮即可)。

---

## #6 · 选择性符号化(④)到底哪些目标激活〔P138 收口〕✅ 已定稿

**结论：作为"技术④"呈现的【不相交区间 / 密度均衡】选择性符号化,在【全部 300s 运行、全部目标】上都
【未激活】——两个开关 `SYMCC_WORKER_DIVERSITY` / `SYMCC_DENSITY_BALANCE` 是 opt-in,基准脚本从未传。**

证据（`util/mpi_fuzzing_helper.py` + `benchmark/run_benchmark.py`）:
- `--symcc-diversity` / `--symcc-density-balance` 均 `store_true` 默认 False（`run_benchmark.py:2365–2374`），
  `run_public_benchmarks.sh` 只传 `--hybrid/--afl-only`,从不传这两个;`benchmark_results_*` 里 grep
  `diversity|density_balance|focus_bytes` **无任何记录**。
- 密度均衡若无密度剖析数据会**静默退回等宽分区**（`_build_work_items` 无密度→等宽切片）。
- 与 #1 一致：旗舰消融里优化④ 因 `symcc_interesting=0` 也未激活。

**唯一可能生效的是**"自动 focus 区间"(`SYMCC_FOCUS_BYTES=min-max±32`,非 flag 门控,≥5 个 interesting
偏移后触发)——按代码路径在 hybrid 里可能触发,但**运行工件里没有采集它的激活日志**(`Runtime.cpp:352`
的 stderr 未落盘)。**P138 稳妥表述**:*"选择性符号化的密度/多样性形态在所有基准运行中均关闭;仅默认
focus 区间启发式【可能】触发,但未对其激活做埋点。"* —— 不要声称④在实验里贡献了覆盖。

---

## #7 · "64B hash" = hex 确认 + 是否改 32B raw〔回应 Q2 必问项〕✅ 已定稿

**结论：是 64 个【十六进制字符】= 一个 32 字节 SHA-256 的 hex 展开(64 ASCII 字节),不是 64 字节原始摘要。**

- 精确代码：`hashlib.sha256(content).hexdigest()`（`mpi_concolic_execution.py:281,655`；
  `mpi_fuzzing_helper.py:854`）——`.hexdigest()` 返回 64 字符串;摘要熵是 32 字节。
- **MPI 线上只传 hash 列表,不传种子内容**(内容走共享 FS,`_atomic_write`);故 hash 就是消息负载。

**是否改传 32B raw（`.digest()`）:** **不建议改。**
- **阻断点**：这个 hash 同时当【文件名】用(`os.path.join(shared_dir, h)`、`save_all_dir/_tc_hash`)。
  32B 原始摘要可能含 `/`(0x2f)和 `\0`(0x00),不能直接做文件名——必须在每个 FS 边界再 hex/base64 编码,
  就不是"一行改动",涉及 ~4 处。
- **收益微乎其微**：每个新 TC 的 hash 传一次 + 广播给其余 master,sqlite 一次跑约 4,369 个 unique TC,
  即便 4 个 master 也就 ~17k 次 × 省 32B ≈ **~0.5 MB / 5 分钟**,远小于共享 FS 上的种子内容,也被 MPI
  信封/pickle 开销淹没;且 master 瓶颈本就是忙等队列扫描(已修),不是 hash 字节。
- **Q2 回应口径**：*"'64B' 指 64 个十六进制字符(SHA-256 的 hex 形式,底层摘要 32 字节);线上只传 hash 不传
  内容。改 32B raw 因 hash 兼作文件名而不划算,ROI 极低,故保持 hex。若真要省字节,已有的 16 字节前缀
  (`_tc_hash[:16]`)比 raw-vs-hex 省得更多,碰撞风险可忽略。"*