Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Use exception stack when available #334

Merged
merged 1 commit into from
Mar 27, 2019
Merged

Conversation

kattrali
Copy link
Contributor

Goal

Improve the debugging experience for caught NSExceptions by providing the exception stack rather than a stack generated at the time notify() is called.

Design

If there is a stacktrace attached to an exception, uses the exception stack rather than generating a new one by passing -[NSException callStackReturnAddresses] as a uintptr_t array to reportUserException. If the exception has not been thrown or the call stack addresses array is null, a stacktrace is generated as before.

Changeset

  • Adding the new stack generation implementation
  • Scoping depth argument to only affect generated stacktraces

Tests

  • Tested manually on a Mac app on macOS 10.13 and on an iOS app running iOS 12.1
  • Added new integration test validating the stacktrace method contents

Review

Outstanding Questions

  • This pull request is ready for:
    • Initial review of the intended approach, not yet feature complete
    • Structural review of the classes, functions, and properties modified
    • Final review

For thrown exceptions, use the exception stack trace rather than a
generated one to allow notify() to be called from a different thread or
handler.
Copy link
Contributor

@fractalwrench fractalwrench left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few comments inline, once those are resolved/addressed I'd be happy with the implementation.

@@ -181,7 +181,8 @@ __deprecated_msg("Use toJson: instead.");
*/
@property(readonly, copy, nonnull) NSDictionary *overrides;
/**
* Number of frames to discard at the top of the stacktrace
* Number of frames to discard at the top of the generated stacktrace.
* Stacktraces from raised exceptions are unaffected.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also update our docs so they state this.

NSArray *addresses = [exception callStackReturnAddresses];
NSUInteger numFrames = [addresses count];
uintptr_t *callstack = malloc(numFrames * sizeof(*callstack));
for (NSUInteger i = 0; i < numFrames; i++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this perform with very large stacktraces e.g. recursion gone wrong? The previous implementation has a limit of 100 frames.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unlimited stack errors can’t be caught and notified. This implementation is more in line with uncaught NSException handling.

block(report);
}
}];
[self notify:exception handledState:state block:block];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this alter the depth of the stack, as there's no longer an extra block?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, technically, however for how we use it, no. This function is only used in cocoa apps in react native, where a custom stacktrace is attached, disregarding depth altogether. And as it isn't a public interface, there should be no other effects.

@kattrali kattrali merged commit aa617d6 into master Mar 27, 2019
@kattrali kattrali deleted the kattrali/macos-test-fix branch March 27, 2019 09:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants