Turn to understand and analyze crash reports for iOS apps

Understand and analyze crash reports for iOS apps

Source URL:

http://developer.apple.com/library/ios/#technotes/tn2151/_index.html

When an application crashes, creating a crash report is useful for understanding how a crash is caused. This document contains basic information about how to identify, understand, and interpret crash reports.

Brief introduction

When an application crashes on an iOS device, a crash report is last created and stored on the device. The crash report describes the conditions under which the application crashes, and in most cases contains a full stack trace of the currently running thread, which is often useful when debugging a problem. If you're an iOS developer, you should review these crash reports to see why your application crashed, and then fix it.

An out-of-memory report differs from other crash reports in that there is no stack trace for this type of report. When a memory crash occurs, you have to look at how your memory is being used and how you handle memory warnings. You may find that this document shows you how several memory management methods are useful.

Crash reports that contain stack traces need to be symbolized (symbolicated) before they can be analyzed. The symbolic process is to replace the memory address with the function name and line number that are easy for people to read. Slip if you get the crash log through Xcode's organizer window, the report will automatically symbolize after a few seconds. Otherwise you will need to import the. crash file into Xcode's organizer for Symbolization. You can use symbolism to learn more details.

Understanding Low Memory reporting

When low memory is detected, iOS's virtual memory system relies on collaboration between applications to free up memory. Out-of-memory notifications are sent to all running applications and processed as memory-freed requests to reduce the amount of memory used. If the memory pressure is always present, then the system may terminate some background processes to reduce the memory pressure. If you can free up enough memory, your application will continue to run without generating a crash report. If not, then your program will be terminated by iOS because there is not enough memory available to meet the application's requirements, and an out-of-memory report will be generated and stored on the device.

An out-of-memory report differs from other crash reports in that there is no stack trace for the application. Memory usage per process is reported based on the number of memory pages, and the size of each memory page volume is 4KB. You will see "Discard (jettisoned)" Immediately after the name of the process that iOS terminated in order to free memory. If you see it immediately following the name of your application, you can be sure that the app is terminated because it uses too much memory. Otherwise, it should not be a crash caused by memory pressure. You can get more information by looking at the. crash file (described in the next section).

When you see an out-of-memory report, you should look at the way you use memory and how you handle it, rather than worrying about which part of your code is being executed at the end of the program. Memory allocations help lists how to use the leak tool (Leaks instrument) to discover memory leaks and how to use the allocation tool (allocations instrument ' s) of the tag heap function to avoid discarded memory. The Memory Usage Performance Guide (performance guidelines) discusses appropriate scenarios like other memory usage tips to respond to out-of-memory notifications. It is also recommended that you take a look at the video in WWSC2010 on using the tool for efficient memory analysis (advanced Instruments).

Attention

The Disclosure and distribution tool cannot track video memory. You need to use the VM Tracker tool (included in the Assignment tool template) to run your app to see how the video memory is being used. VM Tracker is disabled by default. In order to use VM Tracker in your application, click on the tool, select the "Automatic snapshot automatic snapshotting" flag or manually press the "Get Snapshot (Snapshot now)" button.

Analyze Crash reports

Unlike out-of-memory reports, most crash reports contain a stack trace for each thread at the end of the program. This section will discuss such reports.

symbolized

The most interesting part of the crash report is the stack trace at the end of your application execution. This trace is similar to when you stop execution in the debugger, but unfortunately there is no name for the method or function that is considered a symbol. Instead, the 16-bit memory address and the executable code that it points to your application or system framework. You need to map these addresses to symbols. The crash log does not contain local tyrants information when it is output, and you need to symbolize it before you parse the log.

Symbolize-converts a stack-traced address into a source-code method name and line number-A. dsym file that is required for the last binary file of the application to the Apple Store and for the build binaries. These must be exact matches, otherwise your report will not be fully symbolized. The basic requirement is that you keep each build that is distributed to the user (ignoring the details of those distributions) and its. dSYM is consistent.

Attention:

You must save the application's binaries and. dsym files to make it fully symbolic of the crash log. You should pack every build you submit to itunes Connect. The. dsym file and the application binaries should be bound together, whether the build of the underlying version or the build of the subsequent version. Even the same source code, the different built files will not be confused. If you use the "Build and Package" command, they will be automatically placed in a suitable location. Although any location can be searched by spotlight.

Xcode's "pack (Archive)" command makes it easy to keep binary files and. dSYM matches when you use the pack and go ("Product") package (Archive) or press shift+command+b). Xode will collect the binary files of the application and the. dsym files containing the symbolic information and store them in a suitable location under your home directory folder. You can know all the apps you've packaged in "packaged (archived)" under Organizer in Xcode. Xcode automatically looks for packaged applications when symbolizing crash logs, and you can package them and submit them directly to itunes Connect, in case you confirm that you want the publishing application and. dsym files to match.

If Xcode has the binary code and. dsym file for the application that generated the crash log, it is automatically symbolized. Xcode Organizer Symbology is required to provide the crash log and the corresponding binaries and. dsym files. Open Xcode Organizer, select "Device (Devices)", select "Device Log" under "Library" at the top of the sidebar, click the Import button, Select the. crash file that needs to be symbolized, and when these steps are complete, Xcode automatically signs the crash log and displays the results.

Exception code

In the 16 lines of the crash log, you can see the line starting with one or more 16 binary values, which represent the special code of the processor that can provide you with more information about the nature of the crash. You can tell by this code that the application crash is due to a program error (for example, bad memory access, an exception, and so on) or some other reason, such as:

1) The exception code 0x8badf00d indicates that the application has been terminated by iOS due to a watchdog timeout. The application took too long to load, terminating or responding to system time. A common cause is network synchronization in the main thread (synchronous networking on the main thread.).

2) Exception code 0xbad22222 indicates that a VoIP application is terminated by iOS due to frequent reboots.

3) Exception code 0xdead10cc indicates that an application was terminated by iOS because it locked system resources (such as a contact database) while it was running in the background.

4) Exception code 0XDEADFA11 indicates that an application is forcibly exited by the user. When the user presses the on key for the first time until the "move slide lock off" screen appears, then press the home button. The reasonable assumption that the user is doing so is that the application becomes slow to translate, but is not sure that any application can force the exit.

Tips:

Terminating a paused application from a multi-task window does not generate a crash log. Once an app is paused, it is eligible for iOS to terminate at any time, so no crash logs are generated.

<!--endfragment-->