ohos-issue-graphics-cppcrash-analysis

Analyze OpenHarmony cppcrash logs to locate native graphics crash root causes.

31|6|Updated Jan 29, 2026
One-click install
npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill ohos-issue-graphics-cppcrash-analysis
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ohos-issue-graphics-cppcrash-analysis
Source: https://github.com/openharmonyinsight/openharmony-skills/tree/main/skills/ohos-issue-graphics-cppcrash-analysis
Command: npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill ohos-issue-graphics-cppcrash-analysis

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It helps you analyze OpenHarmony cppcrash fault logs from the native graphics stack to identify the true root cause of process crashes and provide exact source-code locations.

Core Features & Use Cases

  • cppcrash-native fault triage: Determines crash type (e.g., SIGSEGV/SIGABRT) and applies address-pattern rules such as Use-After-Free signatures (e.g., 0x6b6b...).
  • Symbol-based stack unwinding: Validates buildId matching and maps crash offsets to precise file:line results using unstripped libraries.
  • Evidence-driven diagnostics: Performs disassembly inspection, memory pattern matching, call-chain backtrace, and (when present) multi-thread competition analysis, then outputs a structured root-cause report with actionable fix recommendations.

Quick Start

Ask the AI to run ohos-issue-graphics-cppcrash-analysis on your cppcrash log with the matching code/ directory and the corresponding lib.unstripped/ symbol files to generate a root-cause report with exact file and line number.

Frequently Asked Questions about ohos-issue-graphics-cppcrash-analysis

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I analyze a native cppcrash log in OpenHarmony graphics components?

To analyze an OpenHarmony cppcrash log, validate buildId matching and map crash offsets to precise file:line results using unstripped libraries, applying address-pattern rules like Use-After-Free signatures for SIGSEGV/SIGABRT incidents.

What does a Use-After-Free signature look like in a native graphics crash?

A Use-After-Free signature in a native graphics crash appears as specific memory address patterns like 0x6b6b... in the crash Reason and registers, indicating memory corruption that requires symbol-based stack unwinding to diagnose.

How do I locate the exact source-code line for a render_service SIGSEGV crash?

To locate the exact source-code line for a render_service SIGSEGV crash, provide the cppcrash fault log with the matching code/ directory and lib.unstripped/ symbol files to validate buildId and perform stack unwinding.

Can I diagnose multi-thread competition issues from an OpenHarmony cppcrash fault log?

Yes, you can diagnose multi-thread competition issues from an OpenHarmony cppcrash fault log by performing call-chain backtrace and memory pattern matching alongside disassembly inspection when thread competition data is present.

Do I need unstripped symbol files to perform native crash analysis on OpenHarmony?

Yes, buildId-verified unstripped symbol files from lib.unstripped/ are required to map crash offsets to precise file:line results during native crash analysis on OpenHarmony graphics components.

What is the best way to troubleshoot memory corruption in the OpenHarmony graphics stack?

The best way to troubleshoot memory corruption in the OpenHarmony graphics stack is evidence-driven diagnostics: combining disassembly inspection, memory pattern matching, and call-chain backtrace to output a structured root-cause report with actionable fixes.