This patch changes Firefox Health Report to pull crash counts from the
newly-implemented crash manager. The crash manager is now the canonical
source of crash data, so all the code for reading crash dump files from
disk has been removed.
This regresses the collection capability of Firefox Health Report by
removing plugin crashes and hangs from the reported values. This
regression is intended to be temporary and a follow-up bug will be
created to add plugin process event recording to the crash events
system.
This regression has been justified because the old crash reporting
mechanism was severely flawed and wasn't sending accurate data (not all
crashes were being saved to dumps and some dumps would be deleted).
--HG--
extra : amend_source : d54bb3bf9f740508cb4eda286536ce16a4c3bee5
This patch changes Firefox Health Report to pull crash counts from the
newly-implemented crash manager. The crash manager is now the canonical
source of crash data, so all the code for reading crash dump files from
disk has been removed.
This regresses the collection capability of Firefox Health Report by
removing plugin crashes and hangs from the reported values. This
regression is intended to be temporary and a follow-up bug will be
created to add plugin process event recording to the crash events
system.
This regression has been justified because the old crash reporting
mechanism was severely flawed and wasn't sending accurate data (not all
crashes were being saved to dumps and some dumps would be deleted).
--HG--
extra : rebase_source : 7442a712d06b4d875010e78d4dd4f5cc179c8dfc
If an xpcshell test called run_next_test() from inside an add_task(),
bad things would happen. This patch detects that behavior and aborts the
test immediately with an actionable error message.
--HG--
extra : rebase_source : c5cf11070421b95a6fcf476d0a86289a3d0ba73a
extra : amend_source : cec6ad2a751bba01e7d4ecbff0735b39e3326efb
This patch institutes limits for how much crash data can be stored in
terms of maximum number of crash events per day. If more events than the
limit are encountered, we record that a high water mark has been
encountered and we silently discard the payload of future events.
We chose to not increment the version of the store payload because no
clients are actively saving this data yet, so it doesn't make sense to
incur a version bump.
--HG--
extra : rebase_source : 3d5d92668b38e8b9c3c45e1a61a3a172b576e0a5
extra : amend_source : 71fffa0724450c5fe13563d2539813e9a831b3de
Support for main process crashes, plugin crashes, and plugin hangs is
added to the crash manager. This includes a JS API for reporting them as
well as support for reading the event files.
There is still an issue of unbound growth on the store. This will be
addressed in a subsequent patch.
--HG--
extra : rebase_source : e714bf5f9c2fd9c50f2e40659c3b1a89591f3b1a
The initial implementation of this feature will write 3 distinct event
types and will only count occurrences of each. Future iterations of the
feature will capture more metadata, such as submission state and extra
crash annotations. These will not be included in this patch set.
DONTBUILD (NPOTB)
--HG--
extra : rebase_source : a1be4ceb6e06f2153d0927e50090c5f352b741d6
This patch introduces the concepts of the "crash data store" and "crash
event files." The "crash data store" is a data store containing
information about crashes. Data is added to this store directly through
a JavaScript API or by the presence of "crash event files." A "crash
event file" is simply an individual file containing information about
a crash event. These files are periodically scanned and their contents
are merged into the store.
Currently, no specific event files types are defined. This patch merely
begins to implement the infrastructure for dealing with them. Support
for specific crash events will be added in subsequent patches.
--HG--
extra : rebase_source : c58017b514f31c2823bc8ef4158a42bba758a9ab
The tree doesn't have a robust and reusable API for interfacing with
crash data. This patch is the start of a new API.
In this patch, the CrashManager type is introduced. It has APIs for
retrieving the lists of files related to crash dumps. In subsequent
patches, I will convert existing code in the tree that does similar
things to the new API. I will also build the events/timeline API onto
this type.
I made CrashManager generic because I hate, hate, hate singletons and
global variables. Allowing it to be instantiated multiple times with
different options (instead of say binding a global instance to ProfD)
makes the testing story much, much nicer. That is reason enough, IMO. In
a subsequent patch, I'll add an XPCOM service that instantiates the
"global" instance of CrashManager with the appropriate options.
It was tempting to add this code into the existing CrashReports.jsm.
However, this file does not import cleanly in xpcshell tests and I
didn't want to bloat scope to include fixing that file... yet.
CrashReports.jsm is using synchronous I/O. So, depending on how
adventerous I feel, I may replace consumers of CrashReports.jsm with the
new CrashManager.jsm, remove CrashReports.jsm, and eliminate another
source of synchronous I/O in the tree.
--HG--
extra : rebase_source : 379fa6a78b53bc0dea0c7c64e8b1bdcf85b61a7c
