菜单
Use when analyzing OpenHarmony cppcrash faultlogs to locate root cause of native process crashes, investigating SIGSEGV/SIGABRT signals, memory corruption patterns, or call stack anomalies.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill ohos-issue-graphics-cppcrash-analysis命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use when managing GitCode repositories from the terminal with oh-gc CLI — auth, issues, PRs, reviewers, testers, labels, releases, and repo config. Triggers on oh-gc commands, GitCode issue/PR management, or when user wants to interact with GitCode without a browser.
对 ArkUI 公共 UI API 与 Android（Compose/View）和 iOS（SwiftUI/UIKit）进行可审计的能力与规格竞品分析。 适用于接口设计评审、能力补齐、Android/iOS 与 ArkUI 迁移评估、API 对标和 capability gap analysis， 覆盖触摸/指针输入、键盘快捷键、手势、组件、布局、状态和动画。要求锁定作用域与版本，以 interface_sdk-js 为 ArkUI 公共接口权威源，优先引用 Android/iOS 官方文档，区分等价关系，并输出带逐项证据、影响和优先级建议的报告。
Use when orchestrating OHOS Phase 0 intake workflow, from raw requirement to IR + proposal splitting + handoff contract. Triggers: requirement intake, Phase 0, requirement review, generate IR, 需求导入, 需求评审, 生成IR. Do NOT use for single-feature design work, Phase 1-9 delivery, ad-hoc document generation, or any task outside the Phase 0 requirement intake workflow.
基于 SOC 职业分类
正在显示 SKILL.md
| name | ohos-issue-graphics-cppcrash-analysis |
| description | Use when analyzing OpenHarmony cppcrash faultlogs to locate root cause of native process crashes, investigating SIGSEGV/SIGABRT signals, memory corruption patterns, or call stack anomalies. |
| metadata | {"author":"openharmony","scope":"domain","stage":"issue","domain":"graphics","capability":"cppcrash-analysis","version":"0.1.0","status":"trial"} |
分析OpenHarmony系统图形模块相关cppcrash日志文件，定位进程崩溃的根本原因。
code/目录下的相关源码lib.unstripped/目录下的带符号表so文件崩溃类型是什么？ → 决定优先分析路径
地址模式有何特征？ → 决定是否需要深度数据流追踪
0x6b6b...开头 → 必须做Use-After-Free分析是否有多线程上下文？ → 决定是否需要竞争分析
Other thread info → 必须检查锁竞争和竞态条件按以下顺序检查：
lib.unstripped/目录是否存在code/目录是否存在若缺失必要输入，终止并报告用户。
从cppcrash头部读取Reason：
0x6b6b开头：Use-After-Free解栈前必须验证so的buildId与cppcrash中一致，否则终止。
根据崩溃类型选择分析路径：
| 崩溃类型 | 优先路径 | 原因 |
|---|---|---|
SIGSEGV + 0x6b6b地址 | 解栈 → 数据流追踪 → 地址匹配 | Use-After-Free需追溯释放点 |
| SIGSEGV + 高位字节异常 | 解栈 → 地址匹配 → 内存分析 | 踩内存需定位踩踏源 |
| SIGABRT + abort/raise | 解栈 → 业务代码分析 | 主动退出需理解退出原因 |
包含cfi_slowpath_comm | 优先踩内存分析路径 | CFI失败指示内存破坏 |
完整流程如下（按需要执行）：
references/stack-unwinding.mdreferences/disassembly-analysis.mdreferences/memory-pattern-analysis.mdreferences/call-chain-backtrace.mdreferences/thread-competition-analysis.mdreferences/memory-data-analysis.mdreferences/special-cases.mdreferences/report-template.md0x6b6b...开头 → Use-After-Free（已释放内存被访问）查看Other thread info：
详见 references/code-review-checklist.md，重点检查：
常见错误做法：
原因：会导致错误的修复方向，浪费调试时间。
常见错误做法：
原因：会导致错误的代码行号定位。
常见错误做法：
原因：多线程问题是图形模块崩溃的常见根因。
常见错误做法：
原因：地址模式匹配是识别内存踩踏的关键手段。
cfi_slowpath_comm → 优先按踩内存问题分析按以下条件读取对应文件：
| 条件 | 文件 | 注意 |
|---|---|---|
| 执行解栈步骤时 | references/stack-unwinding.md | 仅解栈时加载 |
| 执行反汇编分析时 | references/disassembly-analysis.md | 仅需确认崩溃指令时加载 |
| 执行调用链回溯分析时 | references/call-chain-backtrace.md | 仅追溯参数来源时加载 |
| 执行数据流追踪或地址模式匹配时 | references/memory-pattern-analysis.md | 仅地址异常时加载 |
| 执行多线程竞争分析时 | references/thread-competition-analysis.md | 仅有多线程上下文时加载 |
| 执行内存数据分析时 | references/memory-data-analysis.md | 仅需分析内存dump时加载 |
| 判断特殊情况时 | references/special-cases.md | 仅调用栈特征匹配时加载 |
| 排查代码问题时 | references/code-review-checklist.md | 仅定位到代码后加载 |
| 生成分析报告时 | references/report-template.md | 仅最后生成报告时加载 |
Do NOT Load: 不要在分析开始时一次性加载所有references文件，按需加载以节省上下文空间。
用户提供了相关源码在code/目录。
用户提供了相关带符号表信息的so在lib.unstripped/目录。
用户环境提供llvm工具（llvm-readelf/llvm-addr2line/llvm-objdump等）。
分析时使用中文交互，涉及文件均为UTF-8编码。