No matter how careful we are in the process of developing programs, we will always encounter programs that flash back inadvertently. Imagine yourself confidently holding up your App in front of a group of people to perform a feature rehearsal, and the smooth operation is interrupted by a relentless Crash. Think of what Luo said when he launched Smartisan OS, he prepared 10 phones, if one has a problem, he will change another, if 10 failed, he will not make a phone. Without further ado, today I will talk to you about the composition of iOSCrash files and common analysis tools. Understanding Crash Reports on iPhone OS is a great WWDC 2010 video that you should check out sometime. It explains the structure of the Crash file in detail. Of course, if you don’t have time, read this article.
As a developer, it’s especially important to have a learning atmosphere and a networking community, and this is one of my iOS networking groups:812157648, no matter you are small white or big ox welcome to enter, share BAT, Ali interview questions, interview experience, discuss technology, we exchange learning growth together!
Crash file structure
When a program runs a Crash, the system will record the running information at the last moment and store it in a file, which is what we call a Crash file. An iOS Crash log usually consists of the following six parts.1. Process Information
| Incident Idnetifier | Crash report unique identifier, different Crash |
|---|---|
| CrashReporter Key | The unique key corresponding to the device id (not the real device’s UDID, which apple has made unavailable in iOS6 to protect user privacy). Generally, the value is the same when the App of the same version crashes on the same device. |
| Hardware Model | Represents the device type where the Crash occurred. “iPad4,4” in the figure above represents iPad Air |
| Process | The process name that represents Crash is usually the name of our App. [] is the ID of the process at that time |
| Path | XXX. App is actually a Bundle, and the real executable file is actually XXX in the Bundle. If you are interested, you can check the relevant information for yourself, and I will introduce it later if possible |
| Identifier | The Indentifier of your App is usually com.xxx.yyy. XXX indicates the domain name of your company and YYy indicates an App |
| Version | Current App version number, the Info of two fields of plist CFBundleShortVersionString and CFBundleVersion |
| Code Type | CPU architecture of the current App |
| Parent Process | The parent process of the current process. Since iOS apps are usually single-process, the parent process is usually Launchd |
2, the Basic Information
| Date/Time | The time when Crash occurred, a readable string |
|---|---|
| OS Version | System version, the number in () represents the Bulid number |
| Report Version | Currently, the format of Crash logs is basically 104. Different versions may contain different fields |
3. Exception (very important)
| Exception Type | Exception types |
|---|---|
| Exception Subtype: | Exception subtype |
| Crashed Thread | The number of the thread in which the exception occurred |
4, Thread Backtrace 
5, the Thread State 
6, Binary Images 
2. Crash
1, Watchdog timeout Exception Code: 0x8badF00D: eat bad food: don’t block main thread
This will be followed by a description:
Application Specific Information:
Com.xxx. yyy failed to resume in time
For such crashes, we should check whether we did the right thing during App initialization, whether we requested the network in the main thread, or other time-consuming things that blocked the normal initialization process.
Generally, the system allows a maximum of 5S for an App from startup to corresponding user events. If the time exceeds 5S, the App will be terminated by the system. Launch, resume, suspend, and quit all have corresponding time requirements. In Highlight Thread we can see the position used when the call is terminated, xxxAppDelegate plus the line number.
PS. During Xcode debugging, the system will temporarily disable the Watchdog, so you need to use the normal startup mode to discover such problems.
2, User force-quit Exception Codes: When a bug causes the system to fail to respond, long press the power button. When a shutdown confirmation screen appears, press the Home button to close the current program.
3. Low Memory termination is different from the general Crash structure, usually consisting of Free pages, Wired Pages, Purgeable pages, largest process, Colleagues list information about all processes running in the system at the current time.
For more information about Memory warning, see my previous article IOS Memory Warning Levels.
In the running process of App, when the system memory is insufficient, it usually sends a warning first and terminates the programs suspended in the background at the same time. Finally, if the memory is still insufficient, the process of the current foreground will be terminated.
After receiving the memory warning, we should release as much memory as possible. Crash can also be regarded as a kind of protection for App.
例 句 : It’s hard to generalize about Crash due to bugs. In most cases, the Crash log can be used to locate the problem, of course, it does not rule out some difficult and complicated cases to see where the problem is not worth a long time. This can only look at the basic skills, a little bit of search, can always find clues. You can always turn to Google for help when you can’t see it. Someone will always have the same Bug as you
Common Exception Type & Exception Code
1, the Exception Type
- EXC_BAD_ACCESS
This type of Excpetion is the longest Crash we have encountered and is usually used to access memory that has not been accessed. EXC_BAD_ACCESS usually follows the “()” with supplementary information.
SIGSEGV: Usually caused by repeatedly releasing objects, this type should not be seen much after switching ARC.
SIGABRT: Abort is received and exits. Usually the Foundation library container does some checks to protect the state, such as inserting nil into an array.
SEGV :(Segmentation Violation) which represents invalid memory address, such as null pointer, uninitialized pointer, stack overflow, etc.
SIGBUS: Bus error. Unlike SIGSEGV, which accesses invalid addresses, SIGSEGV accesses valid addresses but bus access is abnormal (e.g. address alignment problems)
SIGILL: Attempts to execute an illegal command that may not be recognized or have permissions
- EXC_BAD_INSTRUCTION
Such exceptions are usually caused by threads executing illegal instructions
- EXC_ARITHMETIC
A division by zero error throws such an exception
2, the Exception Code
| 0xbaaaaaad | This type of log means that the Crash log is not a real Crash, it only contains the running status of the whole system at a certain time. This is usually done by pressing both the Home button and the volume button at the same time, possibly triggered by the user’s carelessness |
|---|---|
| 0xbad22222 | When VOIP programs are activated too frequently in the background, the system may terminate such programs |
| 0x8badf00d | This has been introduced before. Watch Dog terminates the program after it takes too long to start or recover |
| 0xc00010ff | The program performs a large number of CPU – and GPU-consuming operations, causing the device to overheat and triggering the system overheat protection to terminate |
| 0xdead10cc | Program back to the background also occupy system resources, such as address book is terminated by the system |
| 0xdeadfa11 | As mentioned earlier, the program is not responding to user force closure |
3. Access to Crash
1. The machine connects to the test machine through xCode, and all Crash logs occurring on the machine can be read directly from the Device.
2. ITunes Connect Obtains Crash logs reported by users through the background of iTunes Connect.
3. There are many excellent third-party Crash collection systems that greatly facilitate Crash collection, and even have the function of symbolizing Crash logs. More commonly used are Crashlytics, Flurry and so on.
Fourth, the appendix
Understanding and Analyzing iOS Application Crash Reports
Technical Note TN2123 CrashReporter
Developer.apple.com/library/ios…
Understanding Crash Reports on the iPhone OS
When Crash logs are recorded, information such as Crash time, function call stack, and thread are written into files. In the next article, we’ll talk about symbolizing Crash logs. In general, it means making Crash logs readable.
Author: smileEvday
The original address: www.cnblogs.com/smileEvday/