Click “like” to see, wechat search [iOS growth refers to north] to guide the book. Welcome to share, please feel free to ask any questions
After reading the book iOS Crash Dump Analysis, we summarized some Crash Analysis techniques.
The preparatory work
Crash report collection
Crash reports online or in development environments can be collected using third-party tools. Let our application be able to handle as many possible signals and exceptions as possible when the application fails, causing the underlying operating system to crash. Use the three-party tool to collect recorded crash information and upload it to the server.
The cost of developing and integrating plcrashReporter into the server should be considered by users themselves
symbolic
Symbolization is the process of mapping machine addresses to symbolic addresses that make sense to programmers who own the source code. When using tripartite crash analysis tools or our own crash analysis service, we should always set up DWARF with dSYM files in Xcode, whether building Debug or Release versions, so that we have a matching dSYM File for each of our builds. We then symbolize the crash reports we get. Save our IPA file and the DSYM file matching it, for the convenience of subsequent use.
The crash reporting tool basically uses atOS commands to symbolize crash reports and provide other system-specific information.
Reverse engineering
Sometimes in our projects, we include third-party binary frameworks that we don’t have source code for. We use Hopper to process our IPA files, then rebase the disassembler and get the same crash address as the program. Find the crashed stack.
Analyze the fault elimination method
Fault analysis provides an analytical method to find problems and facilitate the recurrence of problems. In practice, there are a lot of crashes reported from different customers for different products and product variations as a result of prioritizing different customers. Scientific analysis and problem finding.
Prioritize the problem
For non-crashes or problems, the priority is different. We’ll think in three ways: seriousness, urgency, and growth.
-
Prioritize according to impact
The crash will prevent customers from performing any operations on our application. The most pressing issue for us to address is the issue that affects our revenues. The chat function of social software should not be compromised, and the purchase and payment process of e-commerce software is very important. Log in the application to determine what the customer has done. Identify the largest and most extensive crash use cases as the crash problems that need fixing the most.
The core functions of a piece of software are the functions that the software uses most often
-
Prioritize according to deadlines
To determine the urgency of the bug fix, we need to evaluate the deadline associated with the bug. For iPhone devices, the time of year when a new device comes out (e.g., September each year). New releases usually mean new systems, new users. So in the two to three months between the end of WWDC and the launch of a new phone, any crashes that lead to a failed app store approval or an app being used for the first time become more and more important.
-
Prioritize according to trends
When we see an alarming increase in the number of crashes reported, we need to analyze the trend to assess it. If our app crashes in a new version of iOS, we’ll need more testing for the new version. Privacy-sensitive applications need to pay more attention to the new user protocol, applications using the underlying API_ need to pay more attention to the beta of the new system, and graphing-sensitive applications should focus on new hardware devices and hardware specification updates.
Collect problems and find them
We will have crash reports, customer logs, analysis data, etc. provided with crash information. Finding the cause of the problem from this information is critical for developers.
The following table categorizes the information collected to help developers or operators better prepare for specific actions that indicate problems.
| Item | IS | IS NOT |
|---|---|---|
| WHAT | Seen | Not Seen |
| WHERE | Seen | Not Seen |
| WHEN | Seen | Not Seen |
| EXTENT | Seen | Not Seen |
Refer specifically to the analysis of fault elimination method article, correctly raise your concerns.
Read crash reports
Crash reports make the most intuitive description of a crash problem we have. Knowing and reading crash reports is critical for developers.
Note that the crash reports we analyzed refer to actual crash reports on physical devices. The crashes that occur while debugging the device on the emulator may vary.
The iOS crash report is broken down into the following sections
The Header section
The Header section of the crash report mainly provides an overview of the overall crash situation. We use the crash report header to quickly understand the device on which the crash occurred, the hardware device (iPad or iPhone), and whether the crash occurred in the foreground or background.
| Entry | Meaning |
|---|---|
| Incident Identifier | Unique crash report number |
| CrashReporter Key | Unique identifier of the crashed device |
| Hardware Model | Apple Hardware models (iPad, iPhone) |
| Process | Crashed process name (or number) |
| Path | The full pathname of the crashed program on the device file system |
| Identifier | fromInfo.plistThe Bundle identifier |
| Version | CFBundleVersion; Parentheses areCFBundleVersionString |
| Code Type | The target architecture of the crash process |
| Role | processtask_role. If we are in the background, foreground, or console application, an indicator is displayed. This affects the scheduling priority of processes. |
| Parent Process | Crashed the parent of the process.launchdIs a process starter, usually the parent. |
| Coalition | Task groups are merged so that they can pool resource consumption. |
CFBundleVersion said bundle construction iteration of the version number (published and unpublished) and CFBundleVersionString may want to say is CFBundleShortVersionString said bundle release version number
Date and Version sections
In this part, we are mainly concerned with the specific data in the OS Version section, which is used to determine the Version in which the crash occurred. Sometimes we need to pay attention to the difference between Date/Time and Launch Time, and find that the APP will crash immediately after the customer uses it for a long Time or opens it.
| Entry | Meaning |
|---|---|
| Date/Time | The time of the crash |
| Launch Time | The time the process was initially started before the crash |
| OS Version | Operating system version (Internal version). |
| Baseband Version | Cellular modem firmware version number (for phone calls) orn/a(if the device doesn’t have a cellular modem) (most ipads, iPod touches, etc.) |
| Report Version | Generate the ReportCrash version of the report |
Abnormal part
In this section we will focus on exception types. In the Crash Report article, we detail the various exception types and locate the type of problem based on the exception code.
| Entry | Meaning |
|---|---|
| Exception Type | Exception types in Mach OS |
| Exception Codes | Encoding of exception types, such as attempts to access invalid addresses and supporting information. |
| Exception Note | Displays if the process was killed by the watchdog timerWhat if (this is not a crash)Is displayed when the process crashesEXC_CORPSE_NOTIFY |
| Termination Reason | It gives a namespace (numeric or subsystem name) and one, depending on the casemagic number(Usually a hexadecimal number that looks like an English word). See below for more information on each termination code. |
| Triggered by Thread | The thread in the process that caused the crash |
Abnormal backtracking
When our application detects a problem and asks the operating system to terminate the application, we get the exception traceback portion of the report. This covers situations where you call ABORT, NSException, _NSLockError, or objC_Exception_throw, either actively or indirectly through Swift, Objective-C, or C runtime support libraries.
There is no way to get to the part where the assertion actually happened. But we can assume that the previous section of the filtered system log should do this. Although we use Xcode’s Window-> Devices and Simulators-> Open Console to allow us to recover this information.
When we see exception backtracking in crash reports from customers, we should pay more attention to the console logs of crashed devices.
The thread part
Next comes the thread backtracking part. This will tell us which thread crashed. We should focus some of our efforts on thread 0.
The crash report format probably consists of at least four parts
| Column | Meaning |
|---|---|
| 1 | Stack frame number, last executed is 0. |
| 2 | Binary file execution. |
| 3 | Execution position (frame 0) or return position (after frame 1) |
| 4 + | The name of a symbolic function or the address in a function with an offset |
Thread state section
And then something like that describes the state of the ARM register.
Binary Images
This section is a long list of binaries that the application dynamically loads at load time
Dynamic loaders perform many tasks when preparing binaries for execution. If our binary references other libraries, it will load them. If not, our application cannot be loaded. This is why a crash can occur even before any code in main.m is called.
If our application crashes before calling the main.m code, we should focus on the specific code in this section.
Avoid collapse
Even though we know that the probability of not having a crash at all is extremely low. Most software developers know what they “should” do; Clean code, proper testing, code reviews, etc.
When considering our code and distributing our code, we should do the following:
-
Decouple and encapsulate our code as much as possible: separate the code out and use a specific look and feel to preserve the various paradigms. Try to make various operations can not be divided into different methods, so that we can quickly locate the problem.
-
Appropriate Xcode diagnostic Settings: Use Xcode’s built-in tools for diagnostic analysis. This can slow the compilation process for medium to large projects, but is useful for preventing circumvention crashes. An effective way to reduce application crashes is to incorporate code analysis into our software development process.
-
Memory diagnostics: Most of the unexpected crashes during iOS development are caused by memory problems. It is necessary to perform memory diagnostics at the right time.
Looking forward to
The translation of this book is finished, but not yet. The author has now finished writing the second edition of the book, which presumably includes a chapter on the breakdown of the first Apple Silicon. The second edition of this book should be ready by mid-November, and I will be doing a quick translation along with the release of the new book. I hope readers can like, forward and star this book, and help me complete the translation and proofreading of this book.
My next step is to complete a version of Swift 100 Days with Python 100 Days in mind. After all, I started with Swift 1.0 and gave up. Stay tuned.
communication
The article continues to update every week, you can search “iOS growth refers to north” on wechat to read and urge more. Learn together and grow