* fix(crash-reporting): decode POSIX wait statuses for display and record Windows session-end reasons
Chromium on POSIX hands render/child-process-gone the raw waitpid() status, so
crash reports read "Exit code: 61696" where exit status 241 is meant (field:
61696=exit 241, 9=SIGKILL, 133=SIGTRAP+core, darwin crashed 5=SIGTRAP). Decode
at the display layer only: the stored exitCode stays raw, Windows codes and
launch-failed launch-error codes render unchanged, and the process-gone span
gains a crash.exit_code_decoded attribute.
Also durably record a system_session_end breadcrumb (with WindowSessionEndEvent
reasons) when Windows session-end fires, so bundles can tell OS shutdown from a
user task-kill in killed/exit-1 sweeps.
* test(crash-reporting): pin the exit(0) no-suffix rendering
Adversarial mutation review: removing the exit-0 suppression in
formatCrashReportExitCode survived the suite — nothing pinned that a clean
exit(0) renders without an '(exit status 0)' suffix.
* test(crash-reporting): decode-attribute tests use synchronous child kills
Renderer killed events gain a 250ms sibling-kill settle once the
correlation branch lands, which (a) defers the span past the test's
platform stub so the decode gate reads the real host platform, and (b)
adds a deferred span that breaks the exact sink assertion. The decode
gate is source-agnostic, and a non-recoverable child kill persists
synchronously on every branch of the stack, so coverage is unchanged and
the platform stub is deterministic on any CI host.
* fix(crash-reporting): keep session-end reasons type-safe
* feat(crash-reporting): capture Crashpad minidumps and name the failing CHECK
40% of renderer deaths report exit 0x80000003 (STATUS_BREAKPOINT) — a Chromium
CHECK/DCHECK — and we captured only the exit code, so the cause was structurally
unknowable. Nothing in the tree wired crashReporter at all.
Start Crashpad pre-whenReady and lift the text signature out of the dump:
Chromium stores the fatal log line in the LOG_FATAL annotation, so the check
name, file and line are recoverable with no symbols and no minidump_stackwalk.
Upload stays off. The existing transport is a user-initiated 4 MiB text bundle;
raw dumps are multi-MB binary carrying process memory. Dumps stay on disk and
only the signature rides the existing crash-report flow.
- minidump-stream-reader: bounds-checked view; a truncated dump degrades
- minidump-crashpad-annotations: allowlisted keys (switch-N carries command lines)
- minidump-crash-signature: LOG_FATAL -> file/line, exception, faulting module
- crashpad-capture: polls for the dump, which races process-gone delivery
STA-4469
* refactor(crash-reporting): claim dumps once and match them to the dead process
A newer dump from a different process could be paired to the wrong report, and
two reports in one crash burst could both claim the same file. Match the dump's
own ptype against the process Electron said died, and claim each dump once.
Also let the fatal line use the stack-length budget: a CHECK message truncated
at 240 chars can lose the condition, which is the diagnosis.
Fix the child-type test to match the classifier: GPU exits are recoverable
churn and never become reports, so they must not burn a dump poll either.
STA-4469
* fix(crash-reporting): recover real Electron CHECK logs
Electron 43 Windows dumps carry the Chromium CHECK line in captured memory but omit the claimed LOG_FATAL annotation. Recover only bounded Chromium-formatted fatal/CHECK lines, and prune raw dumps after crash events so suppressed child crash storms stay within the 128 MiB budget.
* fix(crash-reporting): satisfy not-found lint
* feat: add crash report submission flow
* Capture crash-report breadcrumbs
- Add a memory-only crash breadcrumb ring buffer and persist snapshots only
when a crash report is recorded
- Include sanitized recent activity in crash diagnostics and tests
- Prevent dismissing or closing the crash dialog while submission is in flight
Co-authored-by: Orca <help@stably.ai>
* fix: address auto-review findings
* chore: remove crash report preview artifact
---------
Co-authored-by: Orca <help@stably.ai>