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)

All
macOS
task

Tracking

()

RESOLVED FIXED
87 Branch
Tracking Status
thunderbird_esr78 --- wontfix
firefox-esr78 --- wontfix
firefox85 --- wontfix
firefox86 --- wontfix
firefox87 --- fixed

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:

  1. Rename the macros to reflect what they do. [done, bug 1692391]
  2. 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]
  3. Introduce a new macro which actually aborts. [done, bug 1692401]
  4. 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]
  5. Remove the non-aborting macros.
  6. Do another pass over the codebase to make sure that we catch exceptions in the right places. [tracked in bug 1693392]
Type: defect → task
Depends on: 1692391
Depends on: 1692394
Depends on: 1692401
Severity: -- → S2
Priority: -- → P2
Depends on: 1693389
Depends on: 1693392
Depends on: 1693434

I'm declaring this bug fixed, and bug 1693389 and bug 1693392 as follow-up work.

Blocks: 1693389, 1693392
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
No longer depends on: 1693389, 1693392
Resolution: --- → FIXED
Target Milestone: --- → 87 Branch
You need to log in before you can comment on or make changes to this bug.