There was a hard-coded date in test_crash_manager.js of around August 3,
2013. This meant that about a year later we would start to run into
boundary issues since we weren't wrapping Date.now() inside
CrashManager.jsm.
It turns out the actual value of DUMMY_DATE doesn't really matter. So,
the test has been changed to produce a value that is reasonably modern.
While I was debugging this, I noticed we're not getting logging in the
tests. So I added that.
--HG--
extra : rebase_source : 4e5534f5df70b01268790396481bdd3236dd8e8e
extra : amend_source : d73ea0a333fa9b0b9c65d890d6f34cb923861acd
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
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
