Confirmed users
421
edits
Crash reporting overhaul: Difference between revisions
Jump to navigation
Jump to search
Added further information about the crash annotation minidump storage project
(Added information about the minidump storage for crash annotations project) |
(Added further information about the crash annotation minidump storage project) |
||
| Line 45: | Line 45: | ||
* Setting annotations is a relatively expensive process | * Setting annotations is a relatively expensive process | ||
* Some annotations are synthesized at crash time and dealt with ad-hoc code, there is no unified mechanism to handle them together with the others | * Some annotations are synthesized at crash time and dealt with ad-hoc code, there is no unified mechanism to handle them together with the others | ||
Given the above storing the annotations within a minidump would simplify the crash reporting flow, eliminate an additional IPC channel and greatly streamline the effort to store annotations by user code. | |||
=== Plan === | === Plan === | ||
| Line 55: | Line 57: | ||
* Minidump writers need to be modified to identify where the annotations are stored in a process memory, read them and write them out within the minidump | * Minidump writers need to be modified to identify where the annotations are stored in a process memory, read them and write them out within the minidump | ||
* Finally teach the stackwalker tool to look for the annotations in the minidump and print them out | * Finally teach the stackwalker tool to look for the annotations in the minidump and print them out | ||
Additionally some changes will be required to Socorro on the ingestion side. Socorro currently relies on the .extra file contents for filtering. For example annotations containing the product version are used to decide if a crash is coming from a version of Firefox that is very old and thus should be dropped. If we store the annotations within the minidump we need to provide a way for Socorro to extract them without processing the full minidump, so that it can still apply its filtering rules. To this end we need to write a streamlined minidump pre-processor that only extracts this information and provides it in JSON format. This might prove useful for other types of filtering we don't currently do (such as rejecting reports caused by hardware faults or unconditionally accepting those that might indicate security-sensitive issues). The rust-minidump crate provides all the necessary functionality to write this tool. | |||
== Crash reporter client == | == Crash reporter client == | ||