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

Capture trace of error reporting thread and identify with boolean flag #303

Merged
merged 5 commits into from
Sep 3, 2018

Conversation

fractalwrench
Copy link
Contributor

@fractalwrench fractalwrench commented Aug 2, 2018

Goal

Captures the trace of the crashed thread, which was previously omitted, and to identify it with a boolean flag in the serialised JSON.

Changeset

  • Add the current thread trace during serialisation
  • Conditionally write errorReportingThread boolean flag by checking crashed flag

Note: the thread name is not captured due to known limitations with how KSCrash captures this information.

Tests

Added unit tests for general thread serialisation, and for checking that the current thread is now captured. Tested with dashboard.

Review

For the submitter, initial self-review:

  • Commented on code changes inline explain the reasoning behind the approach
  • Reviewed the test cases added for completeness and possible points for discussion
  • A changelog entry was added for the goal of this pull request
  • Check the scope of the changeset - is everything in the diff required for the pull request?
  • 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 the pull request reviewer(s), this changeset has been reviewed for:

  • Consistency across platforms for structures or concepts added or modified
  • Consistency between the changeset and the goal stated above
  • Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
  • Usage friction - is the proposed change in usage cumbersome or complicated?
  • Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
  • Concurrency concerns - if components are accessed asynchronously, what issues will arise
  • Thoroughness of added tests and any missing edge cases
  • Idiomatic use of the language

@fractalwrench fractalwrench requested a review from a team August 2, 2018 12:27
- (void)serialiseThread:(NSMutableArray *)bugsnagThreads
thread:(NSDictionary *)thread
backtrace:(NSArray *)backtrace
crashedThread:(BOOL)isCrashedThread {
Copy link
Contributor

Choose a reason for hiding this comment

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

I would be careful to call this the reportingThread or the currentThread to emphasize that its not the crashing thread in all cases.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This makes sense - I've updated the parameter name.

Copy link
Contributor

@kattrali kattrali left a comment

Choose a reason for hiding this comment

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

Works as expected 👍

There should be a test for this behavior. There is currently one for the thread count, but should also be one to verify that one thread is marked as the reporting thread and that the ID matches the crash thread ID.

@fractalwrench
Copy link
Contributor Author

Labelling as WIP as the mazerunner scenario appears to have failed on Travis CI, and the build queue is currently blocked which means I'm unlikely to investigate this further by the end of today :(

@kattrali
Copy link
Contributor

That’s fine, thanks. Provided it’s not reraised as needing review, it should be fine until you’re done with it.

@fractalwrench fractalwrench removed the wip label Aug 22, 2018
@fractalwrench
Copy link
Contributor Author

fractalwrench commented Aug 22, 2018

Added an additional mazerunner scenario that ensures only one thread is marked as the errorReportingThread from a handled exception.

N.B. the mazerunner scenarios for session tracking currently fail for an unrelated reason which is addressed in #310 (this is now resolved)

@fractalwrench fractalwrench merged commit 86399b8 into next Sep 3, 2018
@fractalwrench fractalwrench deleted the thread-id branch September 3, 2018 08:10
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.

3 participants