We get a number of crash reports that are not actually crashes, but rather reports of cases where there was a problem with killing off a process.

The ipc_channel_error annotation contains "ShutDownKill" for these reports.

We get a number of these crash reports and they aren't very actionable.

Should we throttle these crash reports? If so, how exactly?

I know we already throttle regular crashes so I was thinking of a similar mechanism. If I look at content process top crashers for nightly right now meaningful shutdown kill signatures have thousands-to-hundreds of reports each. So cutting them by a factor 10 should make most of the useless ones go away from the top 50 while keeping the highest volumes ones around.

Ryan WDYT of this approach?

sgtm!

The Socorro collector currently throttles incoming Firefox desktop release channel crashes at 10%--it rejects 90% of them.

Do we want this new throttle rule to throttle all incoming ShutDownKill crashes for all products at 10%? Do we want to pick on specific products or channels?

ShutDownKill crashes happen only on nightly, we don't record them on other channels so that should be the only one affected. I also couldn't find any for GeckoView/Fenix/Focus/etc... so I'd say only Firefox desktop, nightly channel.

Cool!

Grabbing this to do soon.

willkg merged PR #491: "bug 1624949: throttle ShutDownKill crash reports" in a0578b3.

I verified that ShutDownKill crash reports were being throttled in stage, but that some were still getting processed.

I pushed this to prod in bug #1625479.

I emailed the stability list about the change and mentioned it on #stability in Matrix, too. They need to know because Top Crashers and other similar reports will change.

Marking as FIXED.