Use the WER runtime exception module to catch early crashes
Categories
(Toolkit :: Crash Reporting, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox105 | --- | fixed |
People
(Reporter: gsvelto, Assigned: bobowen)
References
Details
Attachments
(2 files)
At the moment we're unable to catch crashes happening during the early stages of startup, and specifically we can't catch crashes happening in firefox.exe before we've started XPCOM initialization, because crash reporting partially depends on it. The WER runtime exception module should have no such limitations so we should try to enable it as soon as possible during startup instead of waiting until Breakpad's exception handler is in place.
Reporter | ||
Comment 1•4 years ago
|
||
This applies to child processes too; since we don't need to wait for XPCOM initialization there too, we can just hook up WER ASAP (we only need to parse the last parameter on the command-line).
Assignee | ||
Comment 2•3 years ago
|
||
I've realised that my work in bug 1759167 is going to move the COM initialization before we have crash reporting, so we would really want this bug first if possible.
The COM initialization move has already happened for the main process, because of the skeleton UI and this explains why we don't get similar COM init crashes for that process.
Assignee | ||
Comment 3•3 years ago
|
||
I have some patches to register this very early on that are working locally.
At the moment it only uses the environment variable controls, because it is so early.
Looks like there is also ini file control of this that I imagine might affect corporate installations more, so that needs some consideration.
Possibly the best we could do is unregister the module once we have read things from the ini file.
Assignee | ||
Comment 4•3 years ago
|
||
Here's a try push with patches from bug 1759167 as well.
Obviously I need to fix up the spidermonkey build.
https://treeherder.mozilla.org/jobs?repo=try&revision=30f01ce8c8eb93692a7d05a0f43fe3dd6c20b2c8
Assignee | ||
Comment 5•3 years ago
|
||
Try push with the spidermonkey stuff fixed:
https://treeherder.mozilla.org/jobs?repo=try&revision=c1d19269b4f88de3ac3c2568a5dfb0785e69313c
Assignee | ||
Comment 6•3 years ago
|
||
This means we can include these files in other binaries when we need earlier
access to the process type and use consistent code.
Assignee | ||
Comment 7•3 years ago
|
||
Depends on D152198
Assignee | ||
Comment 8•3 years ago
|
||
Assignee | ||
Comment 9•3 years ago
|
||
Latest try push after addressing current comments:
https://treeherder.mozilla.org/jobs?repo=try&revision=8b383ade00a1f6aea534acfb9f35c00a6e1342cf
Assignee | ||
Comment 10•3 years ago
|
||
Final (hopefully) try push on reviewed patches:
https://treeherder.mozilla.org/jobs?repo=try&revision=54f4c4c341c44365fc343cacca98e738ca111ebb
Updated•3 years ago
|
Updated•3 years ago
|
Comment 11•3 years ago
|
||
Comment 12•3 years ago
|
||
Backed out for causing build bustages on ProcessType.h
- Backout link
- Push with failures
- Failure Log
- Failure line: builds/worker/workspace/obj-build/dist/include/mozilla/ProcessType.h:33:45: error: inline function 'GeckoProcessType mozilla::GetGeckoProcessType()' declared weak [-Werror=attributes]
Updated•3 years ago
|
Assignee | ||
Comment 13•3 years ago
|
||
New try push, with the build that failed and a few more as well:
https://treeherder.mozilla.org/jobs?repo=try&revision=240f612a769c22082967b1055cadc72264800a56
Comment 14•3 years ago
|
||
Comment 15•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/9cd56f898487
https://hg.mozilla.org/mozilla-central/rev/08607f50a78a
Description
•