Decoding HarmonyOS Native Crashes: Systematic CppCrash Analysis from Signal to Root Cause

Signal Identification: Anchoring Direction from Chaos

The first step in CppCrash log analysis is interpreting the signal. Each signal maps to a distinct crash root-cause category:

SIGSEGV : Invalid memory access (null pointer dereference, out-of-bounds access, use-after-free).

SIGABRT : Process abort (thread deadlock, file descriptor leak, timing issues).

SIGBUS : Misaligned memory access.

SIGILL : Illegal instruction.

In the case study, the crash log shows SIGSEGV(SEGV_MAPERR)@0x006bcc0c4890755c in libc++_shared.so (_release_weak()+40) with ECSConnection::unRefRequest in the call chain. SEGV_MAPERR indicates an attempt to access an address not mapped into the process address space — a strong indicator of use-after-free (UAF), not a simple null pointer (which typically yields SEGV_NULL). The skill's built-in signal semantics knowledge base automatically identifies and interprets these signal combinations to lock in the analysis direction.

Address Decoding: Capturing Characteristics from Hexadecimal

Experienced developers recognize address patterns: 0x00000000: High probability of null pointer dereference. 0x0000000c: Struct member null pointer offset access. 0x006b or 0x6b6b prefix: Strong likelihood of use-after-free — memory freed but pointer not nulled.

Random address with random crash stack: Suspect out-of-bounds access or binary mismatch.

The crash address 0x006bcc0c4890755c starts with 0x006b, matching the UAF address signature. Combined with the signal type, the skill forms an initial hypothesis: this is not a null pointer but a dangling pointer re-access. Register inspection reinforces this: x8 = 0x6b6bcc0c4890753c (close to the crash address) and x9 = 0 (null), indicating a key object was released while its reference remained in use.

Call Stack Parsing and Root Cause Localization: From Offsets to Semantics

Raw crash stack offsets are unreadable. The skill uses llvm-addr2line to resolve offsets into function names and line numbers, making the call chain readable:

#00 pc 00000000000c60e0 libc++_shared.so(_release_weak()+40)

#01 pc 000000000038633c libimsdk.so

#02 pc 000000000027edfc libimsdk.so(ECSConnection::unRefRequest+60)

_release_weak()

is the core C++ shared_ptr / weak_ptr reference-count management function. ECSConnection::unRefRequest ties the crash to enterprise connection service lifecycle management — when the reference count drops to zero, the object is freed, but a weak_ptr still attempts to access its control block, causing access to freed memory. The skill transforms the stack from "address gibberish" into a "business-process fault map."

Synthesizing signal characteristics, address patterns, and call stack semantics, the skill concludes the root cause: ECSConnection object reference-count management is flawed; cross-thread passing leads to lifecycle mismatch, causing the object to be freed while a weak_ptr still tries to access it.

Responsibility Attribution: From Path to Ownership

Determining which module owns the crash avoids blame-shifting. The skill automatically attributes responsibility based on SO path: /data/storage/el1/bundle/ prefix → Application-side module. /system/ prefix → System-side module.

In this case, the crashing module /data/storage/el1/bundle/libs/arm64/libimsdk.so resides in the app data directory, so responsibility lies with the application — even though the crash occurs in the C++ runtime library, the real issue is the app-side ECSConnection lifecycle management.

Structured Report: From Diagnosis to Closure

The skill outputs a complete analysis report containing:

Basic fault information (time, process, signal, address).

Root cause analysis with confidence assessment.

Full evidence chain (signal semantics, address characteristics, register analysis, key call stack frames).

Root cause breakdown (direct cause, deep cause, trigger path).

Root cause module attribution .

Fix recommendations .

This forms a complete diagnostic loop from crash discovery to root cause localization to fix deployment.

Skill Advantages Summary

Efficiency leap : From "manual investigation" to "automated diagnosis," reducing analysis cycle from days to minutes. The skill automates signal identification, address decoding, call stack parsing, and other tedious steps.

Out-of-the-box : All analysis tools ( reliability_analyze, extract_hilog, llvm-addr2line, llvm-objdump) are built in; developers only need to provide logs to start the full analysis pipeline.

Precise localization : Leveraging the HarmonyOS core subsystem reference knowledge base, the skill accurately interprets system-level call stacks — whether recognizing the 0x6b UAF address signature or correlating register states, it catches details human eyes miss.

Diagnostic closure : Covers the full DFX diagnostic chain from ArkTS exceptions to cross-language memory leaks to native crashes, filling the last piece of HarmonyOS native crash diagnosis.

Without this skill, developers might spend days ruling out null pointers, memory leaks, and thread races. Facing a _release_weak() stack, inexperienced developers might suspect a C++ runtime bug. Now, through the systematic flow of signal identification → address decoding → call stack parsing → root cause localization, the crash code is precisely deciphered and the fix direction becomes clear.