Understanding and analyzing crash reports of ios apps and crash reports of ios apps

Understanding and analyzing crash reports of ios apps and crash reports of 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 occurs. This document contains basic information about how to identify, understand, and explain the crash report.

Introduction

When an application crashes on an iOS device, a crash report is created and stored on the device. The crash report describes the conditions under which the application crashes. In most cases, it contains a complete stack trace of the currently running thread, which is usually useful in debugging problems. If you are an iOS developer, you should check these crash reports to find out the cause of your application crash and fix it.

Memory insufficiency reports differ from other crash reports in that such reports do not have stack traces. When a memory crash occurs, you must study how your memory is used and how you handle the memory warning. You may find that this document provides several memory management methods that are very useful.

A crash report containing a stack trace needs to be signed first (Symbolicated. The symbolic process is to replace the memory address with the function name and row number that people can easily read. Slide: If you get the crash log through the Xcode Organizer window, the report will be automatically symbolic in a few seconds. Otherwise, you need to import the. crash file to Xcode's Organizer for symbolic. You can learn more details through symbolic.

Report on memory Insufficiency

When insufficient memory is detected, the virtual memory system of iOS releases the memory based on the cooperation between applications. Notifications with insufficient memory are sent to all running applications and processed as memory release requests to reduce the total memory usage. If the memory pressure persists, the system may terminate some background processes to reduce the memory pressure. If you can release enough memory, your application will continue to run without generating a crash report. If not, your program will be terminated by iOS because there is not enough memory to meet the needs of the application, A report with insufficient memory will be generated and stored on the device.

The out-of-memory report differs from other crash reports in that it does not have application stack tracing. The memory usage of each process is reported based on the number of memory pages. The size of each memory page is 4 kb. You will see that jettisoned follows the name of the process terminated by iOS to release the memory. If you see it following your application name, you can determine that the application is terminated because it uses too much memory. Otherwise, it should not be caused by memory pressure. You can get more information by viewing the. crash file (described in the next section.

When you see a report on memory insufficiency, you should study how you use the memory and how you handle the warning about memory insufficiency, instead of worrying about which part of your code is executed when the program is terminated. Memory Allocations Help lists how to use the leak tool (Leaks Instrument) to detect Memory Leaks and how to use the allocation tool (Allocations instruments's) to avoid discarding the memory. Memory Usage Performance Guidelines discusses an appropriate solution like other Memory Usage tips to respond to out-of-Memory notifications. We also recommend that you take a look at the video (Advanced Memory Analysis with Instruments) on the use of tools for efficient Memory Analysis in WWSC2010 ).

Note:

Leakage and distribution tools cannot trace the video memory. You need to use the VM Tracker tool (included in the allocation tool template) to run your application to observe the usage of the video memory. VM Tracker is disabled by default. To use VM Tracker in your application, click the tool, select the "Automatic Snapshot Automatic Snapshotting" icon, or manually press the "get Snapshot Now" button.

Analyze the crash report

Unlike the memory insufficiency report, most crash reports contain the stack trace of each thread at program termination. This section discusses such reports.

Symbolic

The most interesting part in 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 it does not provide the name of a method or function that is considered to be a symbol. Replace the 16-bit memory address with the executable code that points to your application or system framework. You need to map these addresses to symbols. Crash logs do not contain local information when output. You need to perform symbolic processing before analyzing logs.

Symbolic-convert the stack trace address to the source code method name and line number-the binary file of the application that was last sent to the Apple App Store and the. dSYM file generated when the binary file was created. These must be exactly matched; otherwise, your report cannot be fully symbolic. It is basically required that you maintain the consistency between the build of each distribution to the user (ignoring the distribution details) and its. dSYM.

Note:

You must save the application's binary files and. dSYM files to facilitate the complete symbolic crash log. You should package every build you submit to iTunes Connect .. The dSYM file and the binary file of the application should be bound together, whether it is the construction of the basic version or the construction of the subsequent version. Even with the same source code, different files are not mixed. If you use the "Build and package" command, they will be automatically placed in a suitable location. You can use Spotlight to search for any location.

Xcode's Archive command keeps binary files and. dSYM matching becomes very simple. When you use the packaging Command (by clicking the Product ("Product")-) to package (Archive) or press Shift + Command + B ), xode will include the binary file of the application and. dSYM files are collected together and stored in a suitable location in your home directory folder. You can find all the applications you have packaged in "Archived" under "Organizer" in Xcode. In the symbolic crash log, Xcode automatically searches for packaged applications, and confirms the applications you want to release and. when dSYM files match, you can package them and submit them directly to ITunes Connect.

If Xcode has the binary code and. dSYM file of the application that generates the crash log, it is automatically symbolic. Xcode Organizer provides crash logs and corresponding binary files and. dSYM files. Open Xcode Organizer, select "Devices", select "Device Logs" under "LIBRARY" at the top of the sidebar, and click "import, select. crash file. After these steps are completed, Xcode automatically marks the crash log and displays the result.

Exception Code

In the 16 lines of the crash log, you can see a line starting with one or more hexadecimal values. These numbers represent the special code of the processor, it provides you with more essential information about crashes. You can use the code to identify whether an application crashes due to program errors (such as incorrect memory access, exceptions, and so on) or other reasons, such:

1) The Exception Code 0x8badf00d indicates that the application has been terminated by iOS because of watchdog timeout. The application took too long to load, terminate, or respond to the system. A common cause is network synchronization in the main thread (synchronous networking on the main thread .).

2) The error code 0xbad22222 indicates that a VoIp application is terminated by iOS due to its frequent restart ,.

3) The Exception Code 0xdead10cc indicates that an application is terminated by iOS because it locks system resources (such as the contact database) during background running ).

4) The error code 0xdeadfa11 indicates that an application is forcibly exited by the user. When the user presses the unlock key for the first time until the screen appears, and then presses the Home Key. The reasonable assumption that users do this is that the application has become slow to translate, but it is not certain that any application can be forced to exit.

Tip:

Terminating a paused application from the multitasking window does not generate crash logs. Once an application is paused, it is eligible to be terminated by iOS at any time, so no crash logs are generated.

<! -- EndFragment -->