-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
[Dev docs] Debugging documentation #1328
[Dev docs] Debugging documentation #1328
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, I think this is a good start. I'm supportive of merging this soon and iterate if need to. Would be great to have a review from @maicki and hopefully other members of the core team.
## Crashes | ||
|
||
Sometimes, the environment can get into a state where a fatal interrupt signal occurs inside UIKit. The exception could be from an invalid memory address, unrecognized selector, or a typical out of bounds to name a few. Since Texture is fairly robust due to the awesome designers, it is the case sometimes that UIKit is more fragile. It is also likely that crashes will be occurring for a small percentage of your users, visible to you only through Crashlytics. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sometimes, the environment can get into a state where a fatal interrupt signal occurs inside UIKit. The exception could be from an invalid memory address, unrecognized selector, or a typical out of bounds to name a few. Since Texture is fairly robust due to the awesome designers, it is the case sometimes that UIKit is more fragile. It is also likely that crashes will be occurring for a small percentage of your users, visible to you only through Crashlytics. | |
Sometimes, the environment can get into a state where a fatal interrupt signal occurs inside UIKit. The exception could be from an invalid memory address, unrecognized selector, or a typical out of bounds to name a few. Since Texture is fairly robust, it is the case sometimes that UIKit is more fragile. It is also likely that crashes will be occurring for a small percentage of your users, visible to you only through your crash reporting service. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's keep a neutral tone in documentations :)
Sometimes, the environment can get into a state where a fatal interrupt signal occurs inside UIKit. The exception could be from an invalid memory address, unrecognized selector, or a typical out of bounds to name a few. Since Texture is fairly robust due to the awesome designers, it is the case sometimes that UIKit is more fragile. It is also likely that crashes will be occurring for a small percentage of your users, visible to you only through Crashlytics. | ||
|
||
Let's go through an example where @maicki and @hnugyen solved a mysterious and non-deterministic crash. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's go through an example where @maicki and @hnugyen solved a mysterious and non-deterministic crash. | |
Let's go through an example where @maicki and @nguyenhuy solved a mysterious and non-deterministic crash. |
Using `if (ASActivateExperimentalFeature(ASExperimentalSkipClearData)) {` you can safely gate your new logic to a universal experiment that consumers of Texture can opt into. | ||
|
||
@maicki and @hnugyen were then able to confirm that preventing the clearData in the data source change prevented this crash from occurring in the wild. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maicki and @hnugyen were then able to confirm that preventing the clearData in the data source change prevented this crash from occurring in the wild. | |
@maicki and @nguyenhuy were then able to confirm that preventing the clearData in the data source change prevented this crash from occurring in the wild. |
Only filling in what I can here. Two different parts so far, one about the
clearData
crash and how it was understood, tested, and closed. The second part is about using Hopper to get more understanding of crashing environments.