已关闭
CppCrash 新增 LLVM 工具自动发现脚本与步骤零输入校验门禁 对比报告 #37
fangzy0823创建于 9月3日关闭于 9月7日
9月3日 修改标题为 “CppCrash 增加llvm_tools调用脚本 对比报告”，原标题为“CppCrash 增加llvm_tools查找、调用脚本 对比报告”
9月3日 关联了pull request：feat: 步骤零新增输入校验——日志类型与堆栈信息门禁
9月3日 修改了issue 的描述
9月3日 修改标题为 “CppCrash 对比报告”，原标题为“CppCrash 增加llvm_tools调用脚本 对比报告”
fangzy0823
9月3日 评论：
9月3日 评论：
对比分析报告：202609031118(原skill) vs 202609031119(修改后skill)
执行摘要
本报告对比分析了 output\202609031118 和 output\202609031119 两个目录的输出结果。两个版本均包含相同的两个日志文件：
CPP_Crash-SIGABRT(进程主动终止)-SI_TKILL_同步.log- CppCrash 日志appfreeze-com.example.dfx_test-20020194-20260718145543386.log- AppFreeze 日志
核心发现：
- 202609031118：错误地使用 CppCrash 分析技能分析了 AppFreeze 日志，违反了技能职责边界
- 202609031119：正确识别并拒绝分析 AppFreeze 日志，符合技能职责规范
详细对比
1. CppCrash 日志分析对比
202609031118 版本
- 输出文件：
CPP_Crash-SIGABRT(进程主动终止)-SI_TKILL_同步.log(1,145 字节) - 生成报告：
reports\202609031118\CPP_Crash-SIGABRT(进程主动终止)-SI_TKILL_同步.md(12,310 字节) - 根因定位：
- 应用 NAPI 函数
AbortProcess（位于libentry.so）主动调用abort()终止进程 - 触发链：用户点击 Button → MMI 投递触摸事件 → ArkUI 点击识别 → JS 回调 (
cppcrash_sigabrt.ts:361:34) →AbortProcessNAPI →abort()→raise(SIGABRT)
- 应用 NAPI 函数
- 关键证据：
SI_TKILL+from:31335:20020205表明信号由本进程自身投递#02帧AbortProcess位于应用产物路径/data/storage/el1/bundle/libs/arm64/libentry.so- HiLog 时序：15:06:18.186 点击识别 → 15:06:18.189 收到 SIGABRT，间隔 3ms
- 责任领域：应用侧（正确定界）
202609031119 版本
- 输出文件：
CPP_Crash-SIGABRT(进程主动终止)-SI_TKILL_同步.log(957 字节) - 生成报告：
reports/202609031119/CPP_Crash-SIGABRT(进程主动终止)-SI_TKILL_同步.md(10,295 字节) - 根因定位：
- 与 202609031118 完全一致
- 应用 NAPI 函数
AbortProcess主动调用abort()终止进程 - 相同的触发链和证据链
- 责任领域：应用侧（正确定界）
CppCrash 分析结论
✅ 两个版本在 CppCrash 分析上表现一致，均正确定位根因、提供完整证据链、准确定界责任领域。
2. AppFreeze 日志处理对比（关键差异）
202609031118 版本
- 输出文件：
appfreeze-com.example.dfx_test-20020194-20260718145543386.log(1,331 字节) - 生成报告：
reports\202609031118\appfreeze-com.example.dfx_test-20020194-20260718145543386.md(22,216 字节，384 行) - 处理方式：
- ⚠️ 错误地使用 CppCrash 分析技能分析了 AppFreeze 日志
- 虽然识别出这是 AppFreeze（APP_INPUT_BLOCK）而非 CppCrash
- 但仍然生成了完整的分析报告
- 报告内容：
- 正确识别故障类型：AppFreeze（APP_INPUT_BLOCK）
- 根因定位：主线程在
WaitThread函数中执行std::thread::join()同步等待 6 个工作线程，但工作线程的running标志永远为true（停止逻辑被注释掉），导致主线程永久阻塞 - 源码定位：
napi_init.cpp:256-290，running = false的停止逻辑在第 288-289 行被注释掉
- 问题：
- ❌ 违反了技能职责边界：CppCrash 分析技能不应处理 AppFreeze 日志
- ❌ 可能造成技能职责混淆，降低系统的可维护性
202609031119 版本
- 输出文件：
appfreeze-com.example.dfx_test-20020194-20260718145543386.log(1,974 字节) - 生成报告：无（未生成报告）
- 处理方式：
- ✅ 正确地拒绝分析 AppFreeze 日志
- 明确输出："该日志不是 CppCrash 故障日志，无法使用本技能分析"
- 提供了详细的判定依据：
- 文件名前缀为
appfreeze-而非cppcrash- - Reason 为
APP_INPUT_BLOCK（应用输入阻塞） - 无 CppCrash 必备特征（无 Signal、无寄存器、无 Native 调用栈）
- 文件名前缀为
- 建议用户使用专门的 AppFreeze 分析技能
- 优点：
- ✅ 严格遵守技能职责边界
- ✅ 提供清晰的判定依据和建议
- ✅ 符合技能设计规范
AppFreeze 处理结论
✅ 202609031119 版本表现正确，正确识别并拒绝分析非 CppCrash 日志
❌ 202609031118 版本存在严重问题，越界处理了 AppFreeze 日志
对比总结表
| 评估维度 | 202609031118 | 202609031119 | 优胜版本 |
|---|---|---|---|
| CppCrash 根因定位 | ✅ 正确 | ✅ 正确 | 平手 |
| CppCrash 证据链完整性 | ✅ 完整 | ✅ 完整 | 平手 |
| CppCrash 责任定界 | ✅ 正确（应用侧） | ✅ 正确（应用侧） | 平手 |
| CppCrash 报告质量 | ✅ 高质量（12,310 字节） | ✅ 高质量（10,295 字节） | 平手 |
| AppFreeze 识别 | ✅ 识别为 AppFreeze | ✅ 识别为 AppFreeze | 平手 |
| AppFreeze 处理 | ❌ 越界分析 | ✅ 正确拒绝 | 202609031119 |
| 技能职责遵守 | ❌ 违反职责边界 | ✅ 严格遵守 | 202609031119 |
| 输出规范性 | ⚠️ 生成了不应有的报告 | ✅ 未生成越界报告 | 202609031119 |
结论与建议
总体评价
202609031119 版本更优，原因如下：
- 技能职责边界清晰：正确识别 AppFreeze 日志并拒绝分析，严格遵守 CppCrash 分析技能的职责范围
- 输出规范：未生成越界的 AppFreeze 分析报告，避免了技能职责混淆
- 用户指引明确：提供了清晰的判定依据和建议，引导用户使用正确的技能
202609031118 版本存在严重问题：
- 越界处理：虽然正确识别了 AppFreeze 日志，但仍然进行了分析，违反了技能职责边界
- 输出混乱：生成了不应有的 AppFreeze 分析报告，可能导致技能职责混淆
- 可维护性风险：如果允许技能越界处理，将降低系统的可维护性和可扩展性
改进建议
系统层面建议
- 统一技能路由机制：在所有分析技能入口建立统一的日志类型校验机制
- 建立技能职责文档：明确每个技能的处理范围和拒绝规则
- 增加自动化测试：验证技能在接收到非目标日志类型时的拒绝行为
附录：关键文件清单
202609031118 输出
output/202609031118/
├── CPP_Crash-SIGABRT(进程主动终止)-SI_TKILL_同步.log (1,145 字节)
└── appfreeze-com.example.dfx_test-20020194-20260718145543386.log (1,331 字节)
reports/202609031118/
├── CPP_Crash-SIGABRT(进程主动终止)-SI_TKILL_同步.md (12,310 字节) ✅
└── appfreeze-com.example.dfx_test-20020194-20260718145543386.md (22,216 字节) ❌ 越界报告
202609031119 输出
output/202609031119/
├── CPP_Crash-SIGABRT(进程主动终止)-SI_TKILL_同步.log (957 字节)
└── appfreeze-com.example.dfx_test-20020194-20260718145543386.log (1,974 字节)
reports/202609031119/
└── CPP_Crash-SIGABRT(进程主动终止)-SI_TKILL_同步.md (10,295 字节) ✅
报告生成时间：2026-09-03
对比分析完成：2026-09-03
9月3日 修改了issue 的描述
9月3日 修改了issue 的描述
9月7日 关闭了 issue
9月7日 issue状态由 待办的 改变为 已完成
9月8日 修改标题为 “CppCrash 新增 LLVM 工具自动发现脚本与步骤零输入校验门禁 对比报告”，原标题为“CppCrash 对比报告”
CppCrash 报告对比分析综合报告
对比背景
本报告对以下两份 CppCrash 分析报告进行横向对比：
reports/202609031022/CPP_Crash-SIGBUS(非法内存访问)-BUS_ADRALN_同步-7.0B33.mdreports/202609031023/CPP_Crash-SIGBUS(非法内存访问)-BUS_ADRALN_同步-7.0B33.md两份报告分析的是同一崩溃事件：
一、根因诊断对比
str x0, [sp]触发硬件对齐异常orr x0, x0, #0x1），精确到具体汇编指令二、证据链完整性对比
2.1 信号与子码分析
两份报告对 SIGBUS(BUS_ADRALN) 的语义解读基本一致，均正确指出：
差异：报告 B 额外补充了"精确异常"概念，说明该异常由硬件在指令执行时立即触发（非延迟异常），技术表述更严谨。
2.2 寄存器与故障地址分析
2.3 调用栈分析
2.4 源码与反汇编（核心差异）
__attribute__((optnone))和完整内联汇编代码str x0, [sp]报告 B 提供的关键证据：
源码（app_crash.cpp:163-178）：
__attribute__((optnone)) napi_value TriggerStackAlign(napi_env env, napi_callback_info info) { #if defined(__aarch64__) asm volatile("mov x0, sp\n" "orr x0, x0, #0x1\n" // 使栈指针未对齐 "mov sp, x0\n" // 设置未对齐栈指针 "str x0, [sp]\n" // 尝试使用未对齐栈 ← 崩溃点 : : : "x0", "sp", "memory"); #endif napi_value result; napi_get_null(env, &result); return result; }反汇编（test_files/libentry.objdump）：
2.5 Memory Near / Maps 辅助证据
两份报告均确认：
差异：报告 B 额外指出"x0/sp 附近栈内存（FaultStack）内容为正常的栈帧数据，无内存破坏迹象，排除踩内存第 2 场景"，明确排除了内存破坏可能性。
三、根因模块定界对比
四、修复建议对比
#ifdef DFX_TEST隔离测试代码五、进一步分析项对比
六、综合评价
七、结论与建议
对比结论
根因判断一致性：两份报告对崩溃根因的判断完全一致，均正确识别为应用函数 TriggerStackAlign 故意破坏 SP 对齐触发 SIGBUS(BUS_ADRALN)。
证据链完整性差异：报告 B 在证据完整性上有质的提升：
str x0, [sp]）分析深度差异：报告 B 的分析更具确定性：
报告 A 的优势：ESR 解码更完整（EC=0x25, ISS=0x0），报告 B 未单独展开 ESR 分析。
改进建议
对报告 A 的改进建议：
对报告 B 的改进建议：
对后续报告生成的建议：
附录：报告质量评分