Repository navigation
Conversation
A native crash raised by the kernel for a fault (SIGSEGV, SIGBUS, SIGILL, SIGFPE, SIGTRAP with a signal-specific si_code) now carries its faulting address from exception.signal.address, normalized to "0x..." without leading zeros, as the crash.fault_address attribute. The message keeps naming only the signal and its code, so every occurrence of one fault still shares one message and one issue. A signal sent by a process (SI_USER, SI_TKILL, ..., including abort()) reports no fault address: for those the system fills the address field with the sender's pid and uid.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
A native crash raised by the kernel for a fault now reports its faulting address as the
crash.fault_addressattribute (for example0x0for a null pointer dereference).exception.signal.addressof the system'sAPP_CRASHevent, which the SDK already received but dropped. It arrives in two spellings (000000000000000000and0x...); both are normalized to0x+ hex without leading zeros.si_code(1 to 0x7f). For a signal a process sent (SI_USER,SI_TKILL, ... —abort()among them) the system fills the field with the sender's pid and uid, so no address is reported.SIGSEGV(SEGV_MAPERR)): the address differs between occurrences of one fault, so it stays out of the message and issue grouping is unaffected.Other threads' stacks (
error.threads) and memory at the fault were already reported fromparams.threads/params.memory; this change does not touch them.Verification
node scripts/unit-node/run.mjs— 624 passed (2 new tests, with negative controls for sent signals,SI_KERNEL, missing code / address / signal).scripts/ci-check.sh— all checks passed (HARs, demo HAP, hvigor plugin task, unit-test compile).error.typeSIGSEGV, messageSIGSEGV(SEGV_MAPERR),crash.fault_address0x0, 39 threads.abort():error.typeSIGABRT, messageSIGABRT(SI_TKILL), nocrash.fault_address, 38 threads.