Parent-generated paired-minidump reports (ShutDownKill, GPUProcessKill) no longer submitted on Nightly since bug 1955963
Categories
(Toolkit :: Crash Reporting, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr140 | --- | unaffected |
| firefox-esr153 | --- | unaffected |
| firefox152 | --- | unaffected |
| firefox153 | --- | unaffected |
| firefox154 | --- | wontfix |
| firefox155 | --- | wontfix |
| firefox156 | --- | fix-optional |
People
(Reporter: jstutte, Unassigned)
References
(Depends on 1 open bug, Regression)
Details
(Keywords: regression)
Since the June 22 2026 re-landing of bug 1955963 ("Let the crash helper extract global annotations on its own"), the family of parent-generated paired-minidump crash reports stopped being generated/submitted on Nightly. This is the ContentParent::GeneratePairedMinidump / CrashReporterHost::GenerateMinidumpAndPair path, where the parent process dumps a hung or killed child on demand and sets the ipc_channel_error annotation.
Two signatures are affected (both Nightly-only -- on beta/release these paths exit silently):
IPCError-browser | ShutDownKill(content process killed byContentParent::KillHardat shutdown)IPCError-browser | GPUProcessKill
Both dropped from normal volume to ~zero at the exact same Nightly build boundary.
Evidence (Firefox / Nightly, via SuperSearch):
- Last build that still produced these reports:
20260621215606(Jun 21 21:56 UTC) -- 248 ShutDownKill, 21 GPUProcessKill. - First substantial build without them:
20260622195746(Jun 22 19:57 UTC) -- 0 and 0 (~85 ShutDownKill expected from its overall crash volume). - Every Nightly build >= Jun 22 produced ~0 of either signature over the following 3+ weeks, while still logging thousands of other crashes, so crash reporting is otherwise healthy.
- Pre-Jun-22 builds keep reporting both signatures through July. The drop is build-correlated (baked into the build), not a server-side/config change.
This is specifically the parent-initiated on-demand dump path: child-initiated crashes (e.g. OOM, JS GC) that also carry a paired browser minidump are unaffected, and content+paired totals are flat across the boundary. The reports are not being re-signatured; they are simply not produced.
bug 1955963 makes the crash helper stop the main process and read its annotations directly, reworking the main-process annotation flow these on-demand dumps rely on (the parent sets ipc_channel_error as a main-process nsCString immediately before requesting the dump). The patch has a history of regressions from this behavior (backed out Apr 30, and May 15 for bug 2038769).
Impact: Nightly ShutDownKill triage (meta bug 1279293) and GPU-process-kill monitoring are blind from Jun 22 2026 onward. The underlying hangs/kills still occur; only the reports are missing.
| Reporter | ||
Updated•1 month ago
|
Comment 1•1 month ago
|
||
Set release status flags based on info from the regressing bug 1955963
Comment 2•1 month ago
|
||
The situation here is a bit ironic, the issue stems from this line. Previous to landing the last patch in bug 1955963 that line would read the main process crash annotations from the main process itself and then add them to the final crash report. After landing bug 1955963 those annotations are read only from the crash helper and the AddSharedAnnotations() functions doesn't read them anymore, so we're generating the crash report but it's missing the main process annotations. To solve this I need to fix bug 1949178 which I was already working on, because that moves all this code to the crash helper and thus solves the annotations problem altogether.
Comment 3•1 month ago
|
||
Set release status flags based on info from the regressing bug 1955963
Comment 4•1 month ago
|
||
The severity field is not set for this bug.
:gsvelto, could you have a look please?
For more information, please visit BugBot documentation.
Updated•1 month ago
|
Updated•1 month ago
|
Updated•13 days ago
|
Updated•9 days ago
|
Description
•