Closed
Bug 1692375
Opened 3 years ago
Closed 3 years ago
Clean up our Objective C exception handling story a little
Categories
(Core :: Widget: Cocoa, task, P2)
Tracking
()
RESOLVED
FIXED
87 Branch
People
(Reporter: mstange, Assigned: mstange)
References
(Blocks 2 open bugs)
Details
Currently we try to make sure that Objective C exceptions don't propagate into C/C++ code because it would cause all kinds of trouble.
We do this with NS_OBJC_BEGIN/END_TRY_ABORT_BLOCK*
macros that are placed in strategic spots. Those macros catch any exception, log its description, and keep going.
There are various problems with this:
- The macros have
ABORT
in their name but don't actually abort. - Ignoring exceptions is a rather unsafe default. Much of our code is not written with the expectation of being abandoned in the middle, and this can result in broken invariants and generally bad state.
- We have no insight into which exceptions fire where and how often. The exception names end up in crash reports, but only if something else later on causes a crash.
- The stack at which the exception was thrown is lost.
- The stack at which the exception was caught is also lost.
- It's unclear whether we're catching exceptions in all the right spots.
I propose the following plan:
- Rename the macros to reflect what they do. [done, bug 1692391]
- Append
exception.callStackReturnAddresses
to the crash report notes so that we know where the exception was thrown. We'll need to symbolicate these addresses manually, which is annoying but doable. [done, bug 1692394] - Introduce a new macro which actually aborts. [done, bug 1692401]
- Gradually convert all usages of the old macros to the new aborting macro. This will introduce new crashes that tell us which places need fixing, and it'll get us to a generally safer place. Also, for any expected exceptions, add custom handling. [tracked in bug 1693389]
- Remove the non-aborting macros.
- Do another pass over the codebase to make sure that we catch exceptions in the right places. [tracked in bug 1693392]
Assignee | ||
Updated•3 years ago
|
Type: defect → task
Updated•3 years ago
|
Severity: -- → S2
Priority: -- → P2
Assignee | ||
Comment 1•3 years ago
|
||
I'm declaring this bug fixed, and bug 1693389 and bug 1693392 as follow-up work.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox85:
--- → wontfix
status-firefox86:
--- → wontfix
status-firefox87:
--- → fixed
status-firefox-esr78:
--- → wontfix
status-thunderbird_esr78:
--- → wontfix
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch
You need to log in
before you can comment on or make changes to this bug.
Description
•