Closed
Bug 1362457
Opened 7 years ago
Closed 7 years ago
No crash report generated for extension process crashes
Categories
(WebExtensions :: General, enhancement, P1)
WebExtensions
General
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: aswan, Assigned: rhelmer)
References
(Blocks 1 open bug)
Details
(Whiteboard: triaged)
The summary pretty much covers it.
Updated•7 years ago
|
Assignee: nobody → kmaglione+bmo
Priority: -- → P1
Whiteboard: triaged
Assignee | ||
Updated•7 years ago
|
Assignee: kmaglione+bmo → rhelmer
Assignee | ||
Comment 1•7 years ago
|
||
The problem is that crash reporting needs to be enabled both in the build (`--enable-crashreporter`) and also at runtime (`MOZ_CRASHREPORTER=1` in environment) However `mach` doesn't seem to honor this environment variable and seems to be disabling this. Running the firefox binary out of the objdir seems to work, and glandium just pointed out to me in IRC that mach run takes the same command as the build-time flag above (`mach run --enable-crash-reporter` - note the extra dash in crash-reporter :/) Anyway! So it's working and here's a crash report: https://crash-stats.mozilla.com/report/index/58a10318-7e27-4ca2-8c04-738870170515 Some things to note: * no symbolication because it's from my local build and crash-stats doesn't have the debug symbols, natch * it's marked as a content process and we don't seem to be sending reportType in the metadata to crash-stats So minimum next steps are: 1) send reportType to crash-stats and get it exposed (and make sure they are differentiated from web content crashes in searches etc) 2) get a test in place to make sure crashes from the extension process work and produce the correct metadata For #2 I think we'll need to install a test extension and put a test in place like http://searchfox.org/mozilla-central/source/dom/ipc/tests/test_CrashService_crash.html and at least check that a minidump is generated and the annotations (like "reportType") are OK.
Assignee | ||
Comment 2•7 years ago
|
||
(In reply to Robert Helmer [:rhelmer] from comment #1) > So minimum next steps are: > > 1) send reportType to crash-stats and get it exposed (and make sure they are > differentiated from web content crashes in searches etc) There is a patch for this in bug 1353168 which depends on the current bug. > 2) get a test in place to make sure crashes from the extension process work > and produce the correct metadata This should probably be done in bug 1353168 as well, resolving the current bug.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Comment 3•7 years ago
|
||
rhelmer, how are these crashes supposed to be submitted by users?
Flags: needinfo?(rhelmer)
Assignee | ||
Comment 4•7 years ago
|
||
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > rhelmer, how are these crashes supposed to be submitted by users? Good question. There currently is no UI for this like there is for web content - so they will sit in the users local crash directory until/unless submitted via about:crashes although I believe we'll get the Telemetry crash ping automatically. So far I don't know of any plan for how to handle extension process crashes, having some kind of UI to submit should be part of such a plan. At this point I think it should be a new bug and block bug 1353168 (if there isn't one already)
Assignee | ||
Comment 5•7 years ago
|
||
Also FWIW I mispelled "RemoteType" as "reportType" above, it is correct in bug 1353168 comment 5 (and requires the patch from that bug)
Flags: needinfo?(rhelmer)
Updated•6 years ago
|
Product: Toolkit → WebExtensions
You need to log in
before you can comment on or make changes to this bug.
Description
•