strictly compare for NSNull values #1138 #1141
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Goal
When attaching a custom stack trace, the stack trace types is sometimes an
NSNull
object. This causes an unhandled error detailed in #1138Design
This strictly checks for
nil
andNSNull
values instead of exclusivelynil
values. It's a bit of a hack.The unhandled errors are universally reported immediately after app start, which would indicate that custom stack trace errors that are stored before the next app launch (like in the event of a simultaneous OOM) are not stored within
BSGKeyStacktrace
. I'm a little lost in this code base so please forgive me not going deeper than ensuringNSNull
values aren't iterated.Changeset
The comparison for
trace
inBugsnagError.m
changed from!= nil
to!(trace == nil || trace == NSNull)
.Testing
This bug has been difficult to reproduce, but the change is additive and so I believe it's a low risk solution with substantial gain (the gain being the Bugsnag error collector does not produce errors itself).