Bugzilla

We have a number of places in the tree that catch Objective C exceptions and [log them to the app notes](https://searchfox.org/mozilla-central/rev/d3343662ce0aced933b30e053b33c93f759292eb/xpcom/base/nsObjCExceptions.h#50). However, we currently only [log exception name and "reason"](https://searchfox.org/mozilla-central/rev/d3343662ce0aced933b30e053b33c93f759292eb/toolkit/crashreporter/mac_utils.mm#22), but not the stack at which the exception was raised.

We should add the exception stack to the app notes.

This is a different stack than the crash stack; after an exception occurs, we usually just move on. We may later crash in a totally different place, or not at all.

`NSException` has a `callStackReturnAddresses` method which performs unwinding synchronously using framepointer stackwalking, and which is fast because it does not perform symbolication. This means we can get the ~full stack in Nightly builds, and partial stacks in Release builds that will at least include the Objective C part of the stack.

This stack will let us see where the exception is triggered and should make it much easier to stop them from firing, or to catch them in a more tightly-scoped fashion.

This bug is step 2 of bug 1692375.

We have a number of places in the tree that catch Objective C exceptions and [log them to the app notes](https://searchfox.org/mozilla-central/rev/d3343662ce0aced933b30e053b33c93f759292eb/xpcom/base/nsObjCExceptions.h#50). However, we currently only [log exception name and "reason"](https://searchfox.org/mozilla-central/rev/d3343662ce0aced933b30e053b33c93f759292eb/toolkit/crashreporter/mac_utils.mm#22), but not the stack at which the exception was thrown.

We should add the exception stack to the app notes.

This is a different stack than the crash stack; after an exception occurs, we usually just move on. We may later crash in a totally different place, or not at all.

`NSException` has a `callStackReturnAddresses` method which performs unwinding synchronously using framepointer stackwalking, and which is fast because it does not perform symbolication. This means we can get the ~full stack in Nightly builds, and partial stacks in Release builds that will at least include the Objective C part of the stack.

This stack will let us see where the exception is triggered and should make it much easier to stop them from firing, or to catch them in a more tightly-scoped fashion.

This bug is step 2 of bug 1692375.

We have a number of places in the tree that catch Objective C exceptions and [log them to the app notes](https://searchfox.org/mozilla-central/rev/d3343662ce0aced933b30e053b33c93f759292eb/xpcom/base/nsObjCExceptions.h#50). However, we currently only [log exception name and "reason"](https://searchfox.org/mozilla-central/rev/d3343662ce0aced933b30e053b33c93f759292eb/toolkit/crashreporter/mac_utils.mm#22), but not the stack at which the exception was thrown.

We should add the exception stack to the app notes.

This is a different stack than the crash stack; after an exception occurs, we usually just move on. We may later crash in a totally different place, or not at all.

`NSException` has a `callStackReturnAddresses` property which contains a callstack from the point where the exception was thrown; it seems that NSException performs unwinding synchronously using framepointer stackwalking when the exception is thrown. Getting the `callStackReturnAddresses` is fast because it does not perform symbolication. This means we can get the ~full stack in Nightly builds, and partial stacks in Release builds that will at least include the Objective C part of the stack.

This stack will let us see where the exception is triggered and should make it much easier to stop them from firing, or to catch them in a more tightly-scoped fashion.

This bug is step 2 of bug 1692375.

We have a number of places in the tree that catch Objective C exceptions and [log them to the app notes](https://searchfox.org/mozilla-central/rev/d3343662ce0aced933b30e053b33c93f759292eb/xpcom/base/nsObjCExceptions.h#50). However, we currently only [log exception name and "reason"](https://searchfox.org/mozilla-central/rev/d3343662ce0aced933b30e053b33c93f759292eb/toolkit/crashreporter/mac_utils.mm#22), but not the stack at which the exception was thrown.

We should add the exception stack to the app notes.

This is a different stack than the crash stack; after an exception occurs, we usually just move on. We may later crash in a totally different place, or not at all.

`NSException` has a `callStackReturnAddresses` property which contains a callstack from the point where the exception was thrown; it seems that NSException eagerly performs a framepointer stackwalk when it is created. Also, getting the `callStackReturnAddresses` is fast because it does not perform symbolication.
Since it's using framepointer stackwalk, this means we can get the ~full stack in Nightly builds, and partial stacks in Release builds that will at least include the Objective C part of the stack.

This stack will let us see where the exception is triggered and should make it much easier to stop them from firing, or to catch them in a more tightly-scoped fashion.

This bug is step 2 of bug 1692375.