iOS app crash log analysis

1. What is a crash log and where can I get it ?

When an app on an iOS device flashes, the operating system generates a crash report, also known as a crash log, to be on the device.

There is a lot of useful information on the crash log, including the circumstances in which the app is being rolled out. Typically, there is full stack trace information for each executing thread, so you can learn what each thread is doing when the flashback occurs, and tell which thread the flashback occurred on.

There are several ways to get a crash log from your device.

When the device syncs with the itunes Store on your computer, it will save the crash log on your computer. Depending on your computer's operating system, the crash log will be saved in the following location:

Mac OS X:~/library/logs/crashreporter/mobiledevice/

Windows XP: c:documentsandsettings<username>applicationdataapplecomputerlogscrashreportermobiledevice <DEVICE_NAME>

Windows Vista or 7: C:users<username>appdataroamingapplecomputerlogscrashreportermobiledevice<device_ Name>

When a user complains about a flashback, you can ask him to sync the device with itunes and, depending on the operating system, download the crash log to the above location and send it to you via email.

You must try to get all the crash logs generated by the user device. Because the more crash logs, the more easily diagnose the problem!

get logs on your device via Xcode : Connect your device to your computer, then use the Command+shift+2 key to open the following screen

Select View Device logs to enter the following screen to clearly see the crash logs on all devices. Find your app name to see all the crash information!

After the app is submitted to the app Store , you can also get a crash log from ITunes connect to the user. Log on to ITunes Connect, select Manage Your applications, click the appropriate app, click the View Details button below the app icon, then click Crash Reports in the links section on the right column.

2. What happens when a crash log is generated ?

There are two main scenarios that create a crash log:

1. application violates operating system rules.

2. There are bugs in the application.

violating iOS rules includes watchdog timeouts on startup, recovery, suspend, exit, user forced exit, and low memory termination. Let us have a detailed look at it.

Watchdog Timeout mechanism

Starting with iOS 4.x , when exiting the app, the app does not terminate immediately, but instead comes back to the background. However, if your app responds quickly enough, the operating system may terminate your app and generate a crash log. These events correspond to the following uiapplicationdelegate:

Application:didfinishlaunchingwithoptions:

Applicationwillresignactive:

Applicationdidenterbackground:

Applicationwillenterforeground:

Applicationdidbecomeactive:

Applicationwillterminate:

Above all of these methods, the application has only a limited amount of time to complete processing. If it takes too long, the operating system terminates the app.

Note: This is very easy to do if you do not place operations that take longer (such as network access) on a background thread. For information on avoiding this situation, please refer to our other two tutorials: Grand Central Dispatch and Nsoperations.

User forced exit

IOS 4.x start to support multi-tasking. If you apply a blocking interface and stop responding, the user can terminate the app by double-clicking the Home button on the home screen . At this point, the action app will generate a crash log.

Note: when you double-click the Home button, you'll see all the apps you've run. Those apps aren't necessarily running, or they're not necessarily suspended.

Typically, when a user taps the home button, the app remains in the background for about 10 minutes, and then the operating system automatically terminates it. So double-clicking the Home button shows a list of apps that are just a series of apps that have been opened in the past. Deleting icons for those apps does not generate any crash logs.

Low memory termination

When you subclass Uiviewcontroller , you may have noticed the didreceivememorywarning method.

apps running in the foreground have the highest level of optimization for accessing and using memory. However, this does not mean that the app can use all the available memory on the device-- only a fraction of the available memory can be used per app.

when memory usage reaches a certain level, the operating system issues a uiapplicationdidreceivememorywarningnotification notification. Also, call the Didreceivememorywarning method.

At this point, in order for the app to continue to function properly, the operating system starts terminating other apps in the background to free up some memory. After all the background apps have been terminated, if your app needs more memory, the operating system will also terminate your app and generate a crash log. In this case, the background app is terminated, and the crash log is not generated.

Note: Depending on the Apple documentation, Xcode does not automatically add a low memory log. You must manually get the logs. However, based on my personal experience, using Xcode 4.5.2, low memory logs are also automatically imported, except that the "Process" and "Type" properties are labeled Unknown (unknown).

Also, it is worth mentioning that allocating a large chunk of memory in a very short period of time will be a huge burden on system memory. In this way, a memory warning notification is also generated.

There are bugs in the app

as you can imagine, mostof the flashbacks are due to bugs in the app, so most crash logs are caused by bugs in the app. There are many kinds of bugs.

in the latter part of the tutorial, you'll learn how to find the problem and fix it by debugging an app with bugs that will generate a crash log!

3. Example of a crash log

Let's take a look at an example of a crash log so that you have a mental spectrum before dealing with some practical problems.

(1) process Information

The first part is information about the process of the flash-back.

Incident Identifier is the unique identifier for the crash report.

Crashreporter Key is the unique key value that corresponds to the device identity. Although it is not a true device identifier, it is also a very useful intelligence: If you see the Crashreporter key value of 100 crash logs is the same, or only a few different crashreport values, it is not a common problem, Occurs on only one or a few devices.

Hardware Model identifies the device type. If many crash logs come from the same device type, the app only has a problem with a particular type of device. In the above log, the crash log produced the device is the iphone 4s.

Process is the app name. The numbers inside the brackets are the process IDs that are applied when the flash is rolledout.

The next few lines are self-explanatory, no need to repeat.

(2) basic information

This section gives some basic information, including the date and time of the flashback, the iOS version of the device . If there are many crash logs from iOS 6.0, the problem only occurs on iOS 6.0.

(3) abnormal

In this section, you can see the type of exception thrown when a flashback occurs. You can also see the exception code and the thread that throws the exception. Depending on the type of crash report, you can see some additional information in this section.

(4) thread backtracking

This section provides a backtracking log of all threads in the app. Backtracking is the list of all active frames when a flashback occurs. It contains a list of functions that are called when a flashback occurs. Look at the following line of logs:

It consists of four columns:

Frame number-- here is 2.

the name of the binary library- here is xyzlib.

the address of the calling method-- here is 0x34648e88.

The fourth column is divided into two sub-columns, one base address and one offset. Here is 0x83000 + 8740, the first digit pointing to the file, and the second number pointing to the line of code in the file.

(5) thread Status

This section is the value in the register of the Flash-back. This part of the information is generally not needed, because the information in the backtracking section is enough to let you find out where the problem lies.

(6) binary image

This section lists the binaries that have been loaded when the flash is rolled out.

4. Symbolic symbolication

The first time you see backtracking on a crash log, you may find it meaningless. We are accustomed to using the method name and the number of rows, rather than a mysterious location like this:

The process of translating these hexadecimal addresses into method names and line numbers is called Symbolization.

After a few seconds after getting the crash log from the Organizer window of Xcode , the crash log is automatically symbolized. The following signed version of the above line is as follows:

Xcode when you symbolize a crash log, you need to access the. DSYM file that is associated with the app binaries on the app Store and the binaries generated. Must match exactly. Otherwise, the log will not be fully symbolized.

Therefore, it is important to keep each compiled version that is distributed to the user. When you archive your app before submitting it, Xcode saves the app's binaries. All archived app files can be found under the Archives tab bar in Xcode organizer.

When a crash log is found, Xcode automatically signs the crash log if there is a matching. DSYM file and application binaries. If you switch to another computer or create a new account, be sure to move all binaries to the correct location so that Xcode can find them.

(Note: You must keep both the app binaries and the. dsym file in order to fully symbolize the crash log.) Every build that is submitted to itunes Connect must be archived.

. DSYM files and binaries are specific bindings for each build and subsequent build, and even from the same source code files, each build is different from other constructs and cannot be replaced with each other.

If you use the build and Archive commands, these files are automatically placed in place. If you are not using the build and archive commands, place them in a location that spotlight can search (such as the home directory). ）

5. low memory flash back

because to be Low Memory collapse collapse log and normal collapse collapse the log is slightly different, so this tutorial Don't separate say Be clear.

IOS when the device detects low memory, the virtual memory system sends notification requests that the app frees the memory. These notifications are sent to all running apps and processes, trying to reclaim some memory .

If memory usage remains high, the systemIntegrationwill beEndStop BackstageLineprocess toSlowSolution Memorypressurepower. If available memory is sufficientenough,should bewith will be able toenough to continueRun and notProductionBirth and collapseCollapse ReportThe report. Nothe,should bewith Will beIOSterminate and generate a low memory crash report.

low memory collapse collapse The log does not have with line stack backtracking. Instead, the above page number enter ( page 4kb

ios release put memory Page End in After the name of the process, you will see jettisoned word sample now in your said end stop.

6. Exception Codes

before studying the real-world flashback scenario, there is one more point to highlight: The interesting exception codes. You can find the exception code in the exception section of the report-the 3rd part of the preceding code. Some encodings are more common.

Typically, the exception code begins with some text, followed by one or more hexadecimal values, which is exactly where the underlying nature of the flashback is. from these encodings, it is possible to distinguish between a program error, illegal memory access, or other reasons.

Here are some common exception encodings:

0x8badf00d: read "Ate bad food"!  ( does the number change to a letter, does it look like:p) The code indicates that the app was terminated by iOS because of a watchdog timeout. It is usually the application that takes too much time to start, stop, or ring the application system events.

0xbad22222: The code indicates that the VoIP application was terminated because it was restarted too frequently.

0xdead10cc: read "deadlock"! This code indicates that the app is terminated because it consumes system resources when it runs in the background, such as when the Contacts database is not released.

0XDEADFA11: read "Dead Fall"! This code indicates that the app was forcibly exited by the user. According to the Apple documentation, the force exit occurs when the user presses the switch button until the "swipe to shut down" appears, and then long press the home button. Forcing the exit will result in a crash log containing the 0XDEADFA11 exception encoding because most of the forced exits are due to the application blocking the interface.

SIGABRT:SIGABRT an exception is caused by an object that receives an non-implemented message

iOS app crash log analysis