bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

Break in three incremental steps the content crash lifecycle




Crash Reporting
7 months ago
7 months ago


(Reporter: gsvelto, Unassigned)


Firefox Tracking Flags

(Not tracked)




7 months ago
+++ This bug was initially created as a clone of Bug #1393716 +++

In bug 1393716 I'm preventing the minidump analyzer from running on crashes that happen upon shutdown, this will lead to a number of crashes missing their stack traces. Minidump analysis is not the only lengthy step we have in the content crash lifecycle, we also send the crash ping which might be a lengthy operation and uses a shutdown blocker for ensuring it's not interrupted by shutdown.

A better approach to handle shutdown (and even crash analysis in general) would be to split this processing in three major steps:

- Recording the crash in the Crash Manager (this includes computing the minidump SHA256 hash and extracting the annotations from the .extra file)

- Extracting the stack traces from the minidump

- Sending the crash ping

A better approach might be to track the state of each crash so we can start with recording it in an unprocessed state, we can then run the stack walking step, record this second step and then send the crash ping and flag the crash as completely processed. This way we might do away with the shutdown blocker and other hacks needed for dealing with shutdown: only recording the crash in the crash manager would happen immediately, the other steps would be done incrementally when the browser is idle. If the browser is shutting down this means that they will simply be delayed until the next startup but we won't miss the stack traces nor the ping.
You need to log in before you can comment on or make changes to this bug.