Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
/* Any copyright is dedicated to the Public Domain.
|
|
|
|
* http://creativecommons.org/publicdomain/zero/1.0/ */
|
|
|
|
|
|
|
|
"use strict";
|
|
|
|
|
|
|
|
const {classes: Cc, interfaces: Ci, utils: Cu} = Components;
|
|
|
|
|
2014-02-14 14:53:47 -08:00
|
|
|
let bsp = Cu.import("resource://gre/modules/CrashManager.jsm", this);
|
2014-01-27 15:49:11 -08:00
|
|
|
Cu.import("resource://gre/modules/Promise.jsm", this);
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
Cu.import("resource://gre/modules/Task.jsm", this);
|
|
|
|
Cu.import("resource://gre/modules/osfile.jsm", this);
|
|
|
|
|
2014-01-27 15:49:11 -08:00
|
|
|
Cu.import("resource://testing-common/CrashManagerTest.jsm", this);
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
|
2014-01-28 15:46:03 -08:00
|
|
|
const DUMMY_DATE = new Date(1391043519000);
|
|
|
|
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
function run_test() {
|
2014-01-27 15:49:11 -08:00
|
|
|
do_get_profile();
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
run_next_test();
|
|
|
|
}
|
|
|
|
|
|
|
|
add_task(function* test_constructor_ok() {
|
|
|
|
let m = new CrashManager({
|
|
|
|
pendingDumpsDir: "/foo",
|
|
|
|
submittedDumpsDir: "/bar",
|
2014-01-27 15:49:11 -08:00
|
|
|
eventsDirs: [],
|
|
|
|
storeDir: "/baz",
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
});
|
2014-01-27 15:49:11 -08:00
|
|
|
Assert.ok(m, "CrashManager can be created.");
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
});
|
|
|
|
|
|
|
|
add_task(function* test_constructor_invalid() {
|
|
|
|
Assert.throws(() => {
|
|
|
|
new CrashManager({foo: true});
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
add_task(function* test_get_manager() {
|
2014-01-27 15:49:11 -08:00
|
|
|
let m = yield getManager();
|
|
|
|
Assert.ok(m, "CrashManager obtained.");
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
|
2014-01-27 15:49:11 -08:00
|
|
|
yield m.createDummyDump(true);
|
|
|
|
yield m.createDummyDump(false);
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
});
|
|
|
|
|
2014-01-27 15:49:11 -08:00
|
|
|
// Unsubmitted dump files on disk are detected properly.
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
add_task(function* test_pending_dumps() {
|
2014-01-27 15:49:11 -08:00
|
|
|
let m = yield getManager();
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
let now = Date.now();
|
|
|
|
let ids = [];
|
|
|
|
const COUNT = 5;
|
|
|
|
|
|
|
|
for (let i = 0; i < COUNT; i++) {
|
2014-01-27 15:49:11 -08:00
|
|
|
ids.push(yield m.createDummyDump(false, new Date(now - i * 86400000)));
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
}
|
2014-01-27 15:49:11 -08:00
|
|
|
yield m.createIgnoredDumpFile("ignored", false);
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
|
|
|
|
let entries = yield m.pendingDumps();
|
|
|
|
Assert.equal(entries.length, COUNT, "proper number detected.");
|
|
|
|
|
|
|
|
for (let entry of entries) {
|
|
|
|
Assert.equal(typeof(entry), "object", "entry is an object");
|
|
|
|
Assert.ok("id" in entry, "id in entry");
|
|
|
|
Assert.ok("path" in entry, "path in entry");
|
|
|
|
Assert.ok("date" in entry, "date in entry");
|
|
|
|
Assert.notEqual(ids.indexOf(entry.id), -1, "ID is known");
|
|
|
|
}
|
|
|
|
|
|
|
|
for (let i = 0; i < COUNT; i++) {
|
|
|
|
Assert.equal(entries[i].id, ids[COUNT-i-1], "Entries sorted by mtime");
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2014-01-27 15:49:11 -08:00
|
|
|
// Submitted dump files on disk are detected properly.
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
add_task(function* test_submitted_dumps() {
|
2014-01-27 15:49:11 -08:00
|
|
|
let m = yield getManager();
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
let COUNT = 5;
|
|
|
|
|
|
|
|
for (let i = 0; i < COUNT; i++) {
|
2014-01-27 15:49:11 -08:00
|
|
|
yield m.createDummyDump(true);
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
}
|
2014-01-27 15:49:11 -08:00
|
|
|
yield m.createIgnoredDumpFile("ignored", true);
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
|
|
|
|
let entries = yield m.submittedDumps();
|
|
|
|
Assert.equal(entries.length, COUNT, "proper number detected.");
|
|
|
|
|
2014-01-27 15:49:11 -08:00
|
|
|
let hrID = yield m.createDummyDump(true, new Date(), true);
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
entries = yield m.submittedDumps();
|
|
|
|
Assert.equal(entries.length, COUNT + 1, "hr- in filename detected.");
|
|
|
|
|
|
|
|
let gotIDs = new Set([e.id for (e of entries)]);
|
|
|
|
Assert.ok(gotIDs.has(hrID));
|
|
|
|
});
|
|
|
|
|
2014-01-27 15:49:11 -08:00
|
|
|
// The store should expire after inactivity.
|
|
|
|
add_task(function* test_store_expires() {
|
|
|
|
let m = yield getManager();
|
|
|
|
|
|
|
|
Object.defineProperty(m, "STORE_EXPIRATION_MS", {
|
|
|
|
value: 250,
|
|
|
|
});
|
|
|
|
|
|
|
|
let store = yield m._getStore();
|
|
|
|
Assert.ok(store);
|
|
|
|
Assert.equal(store, m._store);
|
|
|
|
|
|
|
|
yield sleep(300);
|
|
|
|
Assert.ok(!m._store, "Store has gone away.");
|
|
|
|
});
|
|
|
|
|
|
|
|
// Ensure discovery of unprocessed events files works.
|
|
|
|
add_task(function* test_unprocessed_events_files() {
|
|
|
|
let m = yield getManager();
|
2014-01-28 15:46:03 -08:00
|
|
|
yield m.createEventsFile("1", "test.1", new Date(), "foo", 0);
|
|
|
|
yield m.createEventsFile("2", "test.1", new Date(), "bar", 0);
|
|
|
|
yield m.createEventsFile("1", "test.1", new Date(), "baz", 1);
|
2014-01-27 15:49:11 -08:00
|
|
|
|
|
|
|
let paths = yield m._getUnprocessedEventsFiles();
|
|
|
|
Assert.equal(paths.length, 3);
|
|
|
|
});
|
|
|
|
|
|
|
|
// Ensure only 1 aggregateEventsFiles() is allowed at a time.
|
|
|
|
add_task(function* test_aggregate_events_locking() {
|
|
|
|
let m = yield getManager();
|
|
|
|
|
|
|
|
let p1 = m.aggregateEventsFiles();
|
|
|
|
let p2 = m.aggregateEventsFiles();
|
|
|
|
|
|
|
|
Assert.strictEqual(p1, p2, "Same promise should be returned.");
|
|
|
|
});
|
|
|
|
|
|
|
|
// Malformed events files should be deleted.
|
|
|
|
add_task(function* test_malformed_files_deleted() {
|
|
|
|
let m = yield getManager();
|
|
|
|
|
2014-01-28 15:46:03 -08:00
|
|
|
yield m.createEventsFile("1", "crash.main.1", new Date(), "foo\nbar");
|
2014-01-27 15:49:11 -08:00
|
|
|
|
|
|
|
let count = yield m.aggregateEventsFiles();
|
|
|
|
Assert.equal(count, 1);
|
|
|
|
let crashes = yield m.getCrashes();
|
|
|
|
Assert.equal(crashes.length, 0);
|
|
|
|
|
|
|
|
count = yield m.aggregateEventsFiles();
|
|
|
|
Assert.equal(count, 0);
|
|
|
|
});
|
|
|
|
|
|
|
|
// Unknown event types should be ignored.
|
|
|
|
add_task(function* test_aggregate_ignore_unknown_events() {
|
|
|
|
let m = yield getManager();
|
|
|
|
|
2014-01-28 15:46:03 -08:00
|
|
|
yield m.createEventsFile("1", "crash.main.1", DUMMY_DATE, "id1");
|
|
|
|
yield m.createEventsFile("2", "foobar.1", new Date(), "dummy");
|
2014-01-27 15:49:11 -08:00
|
|
|
|
|
|
|
let count = yield m.aggregateEventsFiles();
|
|
|
|
Assert.equal(count, 2);
|
|
|
|
|
|
|
|
count = yield m.aggregateEventsFiles();
|
|
|
|
Assert.equal(count, 1);
|
|
|
|
|
|
|
|
count = yield m.aggregateEventsFiles();
|
|
|
|
Assert.equal(count, 1);
|
|
|
|
});
|
|
|
|
|
|
|
|
add_task(function* test_prune_old() {
|
|
|
|
let m = yield getManager();
|
|
|
|
let oldDate = new Date(Date.now() - 86400000);
|
|
|
|
let newDate = new Date(Date.now() - 10000);
|
2014-01-28 15:46:03 -08:00
|
|
|
yield m.createEventsFile("1", "crash.main.1", oldDate, "id1");
|
2014-05-12 11:58:18 -07:00
|
|
|
yield m.addCrash(m.PROCESS_TYPE_PLUGIN, m.CRASH_TYPE_CRASH, "id2", newDate);
|
2014-01-27 15:49:11 -08:00
|
|
|
|
|
|
|
yield m.aggregateEventsFiles();
|
|
|
|
|
|
|
|
let crashes = yield m.getCrashes();
|
|
|
|
Assert.equal(crashes.length, 2);
|
|
|
|
|
|
|
|
yield m.pruneOldCrashes(new Date(oldDate.getTime() + 10000));
|
|
|
|
|
|
|
|
crashes = yield m.getCrashes();
|
|
|
|
Assert.equal(crashes.length, 1, "Old crash has been pruned.");
|
|
|
|
|
|
|
|
let c = crashes[0];
|
|
|
|
Assert.equal(c.id, "id2", "Proper crash was pruned.");
|
|
|
|
|
|
|
|
// We can't test exact boundary conditions because dates from filesystem
|
|
|
|
// don't have same guarantees as JS dates.
|
|
|
|
yield m.pruneOldCrashes(new Date(newDate.getTime() + 5000));
|
|
|
|
crashes = yield m.getCrashes();
|
|
|
|
Assert.equal(crashes.length, 0);
|
|
|
|
});
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
|
2014-01-27 15:49:11 -08:00
|
|
|
add_task(function* test_schedule_maintenance() {
|
|
|
|
let m = yield getManager();
|
2014-01-28 15:46:03 -08:00
|
|
|
yield m.createEventsFile("1", "crash.main.1", DUMMY_DATE, "id1");
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
|
2014-01-27 15:49:11 -08:00
|
|
|
let oldDate = new Date(Date.now() - m.PURGE_OLDER_THAN_DAYS * 2 * 24 * 60 * 60 * 1000);
|
2014-01-28 15:46:03 -08:00
|
|
|
yield m.createEventsFile("2", "crash.main.1", oldDate, "id2");
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
|
2014-01-27 15:49:11 -08:00
|
|
|
yield m.scheduleMaintenance(25);
|
|
|
|
let crashes = yield m.getCrashes();
|
|
|
|
Assert.equal(crashes.length, 1);
|
|
|
|
Assert.equal(crashes[0].id, "id1");
|
Bug 875562 - Part 2: Create CrashManager API for managing crash data; r=ted, Yoric
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
2013-11-19 14:08:25 -08:00
|
|
|
});
|
2014-01-28 15:46:03 -08:00
|
|
|
|
|
|
|
add_task(function* test_main_crash_event_file() {
|
|
|
|
let m = yield getManager();
|
|
|
|
yield m.createEventsFile("1", "crash.main.1", DUMMY_DATE, "id1");
|
|
|
|
let count = yield m.aggregateEventsFiles();
|
|
|
|
Assert.equal(count, 1);
|
|
|
|
|
|
|
|
let crashes = yield m.getCrashes();
|
|
|
|
Assert.equal(crashes.length, 1);
|
|
|
|
Assert.equal(crashes[0].id, "id1");
|
|
|
|
Assert.equal(crashes[0].type, "main-crash");
|
|
|
|
Assert.deepEqual(crashes[0].crashDate, DUMMY_DATE);
|
|
|
|
|
|
|
|
count = yield m.aggregateEventsFiles();
|
|
|
|
Assert.equal(count, 0);
|
|
|
|
});
|
|
|
|
|
|
|
|
add_task(function* test_multiline_crash_id_rejected() {
|
|
|
|
let m = yield getManager();
|
|
|
|
yield m.createEventsFile("1", "crash.main.1", DUMMY_DATE, "id1\nid2");
|
|
|
|
yield m.aggregateEventsFiles();
|
|
|
|
let crashes = yield m.getCrashes();
|
|
|
|
Assert.equal(crashes.length, 0);
|
|
|
|
});
|
|
|
|
|
2014-05-12 11:58:18 -07:00
|
|
|
// Main process crashes should be remembered beyond the high water mark.
|
2014-01-28 17:33:38 -08:00
|
|
|
add_task(function* test_high_water_mark() {
|
|
|
|
let m = yield getManager();
|
|
|
|
|
|
|
|
let store = yield m._getStore();
|
|
|
|
|
|
|
|
for (let i = 0; i < store.HIGH_WATER_DAILY_THRESHOLD + 1; i++) {
|
|
|
|
yield m.createEventsFile("m" + i, "crash.main.1", DUMMY_DATE, "m" + i);
|
|
|
|
}
|
|
|
|
|
|
|
|
let count = yield m.aggregateEventsFiles();
|
2014-05-12 11:58:18 -07:00
|
|
|
Assert.equal(count, bsp.CrashStore.prototype.HIGH_WATER_DAILY_THRESHOLD + 1);
|
2014-01-28 17:33:38 -08:00
|
|
|
|
|
|
|
// Need to fetch again in case the first one was garbage collected.
|
|
|
|
store = yield m._getStore();
|
2014-05-12 11:58:18 -07:00
|
|
|
|
|
|
|
Assert.equal(store.crashesCount, store.HIGH_WATER_DAILY_THRESHOLD + 1);
|
|
|
|
});
|
|
|
|
|
|
|
|
add_task(function* test_addCrash() {
|
|
|
|
let m = yield getManager();
|
|
|
|
|
|
|
|
let crashes = yield m.getCrashes();
|
|
|
|
Assert.equal(crashes.length, 0);
|
|
|
|
|
|
|
|
yield m.addCrash(m.PROCESS_TYPE_MAIN, m.CRASH_TYPE_CRASH,
|
|
|
|
"main-crash", DUMMY_DATE);
|
|
|
|
yield m.addCrash(m.PROCESS_TYPE_MAIN, m.CRASH_TYPE_HANG,
|
|
|
|
"main-hang", DUMMY_DATE);
|
|
|
|
yield m.addCrash(m.PROCESS_TYPE_CONTENT, m.CRASH_TYPE_CRASH,
|
|
|
|
"content-crash", DUMMY_DATE);
|
|
|
|
yield m.addCrash(m.PROCESS_TYPE_CONTENT, m.CRASH_TYPE_HANG,
|
|
|
|
"content-hang", DUMMY_DATE);
|
|
|
|
yield m.addCrash(m.PROCESS_TYPE_PLUGIN, m.CRASH_TYPE_CRASH,
|
|
|
|
"plugin-crash", DUMMY_DATE);
|
|
|
|
yield m.addCrash(m.PROCESS_TYPE_PLUGIN, m.CRASH_TYPE_HANG,
|
|
|
|
"plugin-hang", DUMMY_DATE);
|
|
|
|
|
|
|
|
crashes = yield m.getCrashes();
|
|
|
|
Assert.equal(crashes.length, 6);
|
|
|
|
|
|
|
|
let map = new Map(crashes.map(crash => [crash.id, crash]));
|
|
|
|
|
|
|
|
let crash = map.get("main-crash");
|
|
|
|
Assert.ok(!!crash);
|
|
|
|
Assert.equal(crash.crashDate, DUMMY_DATE);
|
|
|
|
Assert.equal(crash.type, m.PROCESS_TYPE_MAIN + "-" + m.CRASH_TYPE_CRASH);
|
|
|
|
Assert.ok(crash.isOfType(m.PROCESS_TYPE_MAIN, m.CRASH_TYPE_CRASH));
|
|
|
|
|
|
|
|
crash = map.get("main-hang");
|
|
|
|
Assert.ok(!!crash);
|
|
|
|
Assert.equal(crash.crashDate, DUMMY_DATE);
|
|
|
|
Assert.equal(crash.type, m.PROCESS_TYPE_MAIN + "-" + m.CRASH_TYPE_HANG);
|
|
|
|
Assert.ok(crash.isOfType(m.PROCESS_TYPE_MAIN, m.CRASH_TYPE_HANG));
|
|
|
|
|
|
|
|
crash = map.get("content-crash");
|
|
|
|
Assert.ok(!!crash);
|
|
|
|
Assert.equal(crash.crashDate, DUMMY_DATE);
|
|
|
|
Assert.equal(crash.type, m.PROCESS_TYPE_CONTENT + "-" + m.CRASH_TYPE_CRASH);
|
|
|
|
Assert.ok(crash.isOfType(m.PROCESS_TYPE_CONTENT, m.CRASH_TYPE_CRASH));
|
|
|
|
|
|
|
|
crash = map.get("content-hang");
|
|
|
|
Assert.ok(!!crash);
|
|
|
|
Assert.equal(crash.crashDate, DUMMY_DATE);
|
|
|
|
Assert.equal(crash.type, m.PROCESS_TYPE_CONTENT + "-" + m.CRASH_TYPE_HANG);
|
|
|
|
Assert.ok(crash.isOfType(m.PROCESS_TYPE_CONTENT, m.CRASH_TYPE_HANG));
|
|
|
|
|
|
|
|
crash = map.get("plugin-crash");
|
|
|
|
Assert.ok(!!crash);
|
|
|
|
Assert.equal(crash.crashDate, DUMMY_DATE);
|
|
|
|
Assert.equal(crash.type, m.PROCESS_TYPE_PLUGIN + "-" + m.CRASH_TYPE_CRASH);
|
|
|
|
Assert.ok(crash.isOfType(m.PROCESS_TYPE_PLUGIN, m.CRASH_TYPE_CRASH));
|
|
|
|
|
|
|
|
crash = map.get("plugin-hang");
|
|
|
|
Assert.ok(!!crash);
|
|
|
|
Assert.equal(crash.crashDate, DUMMY_DATE);
|
|
|
|
Assert.equal(crash.type, m.PROCESS_TYPE_PLUGIN + "-" + m.CRASH_TYPE_HANG);
|
|
|
|
Assert.ok(crash.isOfType(m.PROCESS_TYPE_PLUGIN, m.CRASH_TYPE_HANG));
|
2014-01-28 17:33:38 -08:00
|
|
|
});
|