iOS application crash log uncovered

Original address: http://www.raywenderlich.com/zh-hans/30818/ios%E5%BA%94%E7%94%A8%E5%B4%A9%E6%BA%83%E6%97%A5%E5%BF%97%E6% 8f%ad%e7%a7%98

Click to open the link

This article can also find English here

If you are new here, your may want to subscribe to my RSS feeds or follow me on Twitter. For visiting!

Learn to make sense of crash logs!

The writer is Soheil Moayedi Azarpour, an independent iOS developer.

As an application developer, have you ever had the following experience?
To make sure your application is correct, you must have done a lot of testing before submitting it to the App Store. It also works well on your device, but after the App store, there's a user complaining that it's going to flash!
If you're a perfectionist like me, you want to be perfect for your application. So you open the code to fix the flashback problem ... But where to begin.
The iOS crash log came in handy. In most cases, you can learn about the details and useful information about the flash-back.
With this tutorial, you'll learn about common crash log cases and how to get crash log files from development devices and itunes Connect. You will also learn to sign (symbolication), from log tracking to code. You will also learn to debug an application that will flash back in a pending situation.
Let's get started! What is a crash log, where can I get it?

When an application on iOS device flashes, the operating system generates a crash report, also known as a crash log, that is on the device.
There is a lot of useful information on the crash log, including what happens when the application is backed up. Typically, there is a complete stack trace of each thread that is executing, so you can learn what the threads are doing when the flash-back occurs and identify the thread on which the flash is occurring.
There are several ways to get the crash log from the device.
When the device synchronizes with the itunes Store on your computer, the crash log is saved on your computer. Depending on your computer's operating system, the crash log will be saved in the following locations:
Mac OS X:

~/library/logs/crashreporter/mobiledevice/

Windows XP:

C:documents and Settings<username>application dataapple computerlogscrashreportermobiledevice<device_name >

Windows Vista or 7:

C:users<username>appdataroamingapple computerlogscrashreportermobiledevice<device_name>

When a user complains about a flash, you can ask him to sync the device with itunes, download the crash log in the above location and email it to you, depending on the operating system.
You must try to get all the crash logs generated by the user's device. Because the more crash logs, the easier it is to diagnose the problem!
Also, if you have a Xcode, it's easy to get crash logs from your device via Xcode. Connect the iOS device to your computer, and then turn on the Xcode. Select from the menu barWindowmenu, and then selectOrganizer(the shortcut is shift-cmd-2).
On the Organizer window, selectDevicestab bar. On the navigation panel on the left, selectDevice Logs, as shown in the following illustration:

Look above, there are several Device Logs menu items on the left.LIBRARYThe following device logs is a log of all your devices (once connected to Xcode). The Device Logs below each device is the log for the corresponding device.
Once applied to the App Store, you can also get the user's crash log from ITunes Connect. Log on to the ITunes connect and chooseManage Your Applications, click on the appropriate application, click the application icon below theView Detailsbutton, and then click on the right column links section of theCrash Reports。

If there is no crash log, try clickingRefreshbutton to refresh. If your app is not selling much, or you've just been on the shelves, you may not have any crash logs on your ITunes connect account.
If there is a crash log on the itunes connect, you will see the following figure:

Sometimes, despite a user report Flash, you still don't see the crash report. At this point, it is best to let users send the crash report directly to you.under what circumstances will a crash log be generated?

Two main scenarios will result in a crash log: The application violates operating system rules. There are bugs in the application.

The violation of iOS rules includes watchdog timeouts at startup, recovery, suspend, exit, user forced exit, and low memory termination. Let's learn more about it.
Watchdog timeout mechanism
Starting with iOS 4.x, the application does not terminate immediately, but is retired to the background.
However, if your application does not respond quickly enough, the operating system may terminate your application and produce a crash log. These events correspond to the following uiapplicationdelegate: application:didFinishLaunchingWithOptions:applicationWillResignActive: ApplicationDidEnterBackground:applicationWillEnterForeground:applicationDidBecomeActive: Applicationwillterminate:

All of the above methods, the application has only a limited amount of time to complete processing. If it takes too long, the operating system terminates the application.

Note: This can easily happen if you do not put a lengthy operation, such as network access, on a background thread. For information about avoiding this situation, please refer to our other two tutorials: Grand Dispatch and Nsoperations.

User forced Exit
IOS 4.x is starting to support multitasking. If you apply a blocking interface and stop responding, users can terminate the application by double-clicking the Home button on the main screen. At this point, the operation application will generate a crash log.

Note: after you double-click the home button, you will see all the applications that have been run. Those applications are not necessarily running, and they are not necessarily suspended.
Typically, when a user clicks the home button, the application is kept in the background for about 10 minutes, and the operating system automatically terminates it. So the list of apps displayed by double-clicking the home button just shows that it's a series of apps that have been opened in the past. Deleting those applied icons will not produce any crash logs.

Low Memory termination
When subclasses Uiviewcontroller, you may have noticed the didreceivememorywarning method.
Applications running in the foreground have the highest level of optimization to access and use memory. However, this does not mean that the application can use all the available memory of the device--each application can use only a portion of the available memory.
When memory usage reaches a certain level, the operating system will issue a uiapplicationdidreceivememorywarningnotification notification. Also, call the didreceivememorywarning method.
At this point, in order for the application to continue to function properly, the operating system begins to terminate other applications in the background to free some memory. After all the backend applications are terminated, if your application needs more memory, the operating system will terminate your application and generate a crash log. In this case, the terminated background application does not produce a crash log.

Note: According to the Apple document, Xcode does not automatically add a low memory log. You must manually get the log. 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 marked as unknown (unknown).
Also, it is worth mentioning that allocating a large chunk of memory in a very short time will put a huge burden on system memory. This will also result in notification of memory warnings.

There are bugs in the application
As you can imagine, most flash-back is due to bugs in the application, so most crash logs are generated because of bugs in the application. There are many kinds of bugs.

In the second half of this tutorial, you will learn how to find the problem and fix it by debugging a bug-containing application that will generate a crash log! instance of crash log

Let's take a look at an instance of a crash log so that you have a mental spectrum before dealing with some real problems.
Without further ado, meet your new friend:

1: Process information Incident identifier:30e46451-53fd-4965-896a-457fc11ad05f crashreporter Key:            5A56599D836C4F867F6EEC76AFEE451BF9AE5F31 hardware model:iphone4,1 process:rage Masters [4155] Path: /var/mobile/applications/a5635b22-f5ef-4ceb-94b6-fe158d885014/rage masters.app/rage Masters identifier:rage Mast ERs Version:???
(???) Code type:arm (Native) Parent process:launchd [1]//2: Basic information date/time:2012-10-17 21:39:06.967-0400 OS Ve Rsion:ios 6.0 (10a403) version:104//3: Exception Exception type:00000020 Exception H ighlighted thread:0//4: Threading backtracking thread 0 name:dispatch queue:com.apple.main-thread thread 0:0 libsystem_kernel.dyli                	b 0x327f2eb4 mach_msg_trap + 1 libsystem_kernel.dylib 0x327f3048 mach_msg + 2 corefoundation 0x36bd4040 __cfrunloopservicemachport + 124 3 corefoundation 0x36bd2d9e __cfrunlooprun + 87     8 4 Corefoundation           	0x36b45eb8 cfrunlooprunspecific + 352 5 corefoundation 0x36b45d44 Cfrunloopruninmode + 100 6                    	Cfnetwork 0x32ac343e Cfurlconnectionsendsynchronousrequest + 7 Foundation 0x346e69ba +[nsurlconnection SendSynchronousRequest:returningResponse:error:] + 242 8 Rage Masters 0 x000d4046 0xd2000 + 8262 Thread 1:0 libsystem_kernel.dylib 0x32803d98 __workq_kernreturn + 8 1 libsystem_c.dy Lib 0x3a987cf6 _pthread_workq_return + 2 libsystem_c.dylib 0x3a987a12 _pthread_wqthread + 3 3 libsystem_c.dylib 0x3a9878a0 Start_wqthread + 4/5: Thread state thread 0 crashed with ARM thread states (32-      bit): r0:0x00000000 r1:0x00000000 r2:0x00000001 r3:0x39529fc8 r4:0xffffffff r5:0x2fd7d301  r6:0x2fd7d300 r7:0x2fd7d9d0 r8:0x2fd7d330 r9:0x3adbf8a8 r10:0x2fd7d308 r11:0x00000032 IP: 0x00000025 SP:0X2FD7d2ec lr:0x001bdb25 pc:0x30301838 cpsr:0x00000010//6: Binary imaging Binary images:0xd2000-0xd7fff +rage Mas ters armv7/var/mobile/applications/a5635b22-f5ef-4ceb-94b6-fe158d885014/rage Masters.app/Rage Masters 0x2fe41000- 0X2FE61FFF dyld armv7/usr/lib/dyld 0x327f2000-0x32808fff libsystem_kernel.dylib armv7/usr/lib/system/libsystem_k Ernel.dylib 0x328a8000-0x328bdfff libresolv.9.dylib armv7/usr/lib/libresolv.9.dylib 0x32a70000-0x32b35fff CFNetwo RK Armv7/system/library/frameworks/cfnetwork.framework/cfnetwork 0x32b7a000-0x32cc3fff Libicucore. A.dylib Armv7/usr/lib/libicucore. A.dylib 0x32cc4000-0x32cc5fff Coresurface armv7/system/library/privateframeworks/coresurface.framework/ Coresurface 0x32f65000-0x32f8afff OpenCL Armv7/system/library/privateframeworks/opencl.framework/opencl

The report looks like a heavenly book. :) Let's read it in several parts:
(1) Process information
The first part is the information about the flash-back process. Incident Identifier is the unique identifier for the crash report. The 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 that the Crashreporter key values of the 100 crash logs are the same, or only a few different crashreport values, this is not a universal problem, Occurs only on one or a few devices. The hardware Model identifies the device type. If many crash logs are from the same device type, the application is only problematic on a particular type of device. In the log above, the crash log generates a device that is the iphone 4s. The Process is the name of the application. The numbers inside the brackets are the process IDs that were applied at the time of the flash. The next few lines speak for themselves, and there is no need to repeat them.

(2) basic information
This section gives some basic information, including the date and time of the flash-back, and the iOS version of the device. If there are a lot of crash logs from iOS 6.0, the problem only occurs on iOS 6.0.
(3) exception
In this section, you can see the type of exception thrown when the flash is occurring. You can also see the exception encoding and the thread that threw the exception. Depending on the type of crash report, you can see some additional information in this section.
(4) Thread backtracking
This section provides backtracking logs for all threads in the application. Backtracking is the list of all active frames in the event of a flash-back. It contains a list of calls to the function when the flash-back occurs. Look at the following line of log:

2    xyzlib    0x34648e88    0x83000 + 8740

It includes four columns: Frame number--here is 2. Name of the binary library--here is xyzlib. Call the address of the 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 number points to the file, and the second number points to the line of code in the file.

(5) thread State
This part is the value in the Flash register. This part of the information is generally not needed because the information in the backtracking section is enough to let you figure out what the problem is.
(6) Binary image
This section lists the binaries that were loaded when the flash was rolled. Symbolic Symbolication

The first time you see a retrospective on the crash log, you may find it meaningless. We used to use method names and lines rather than mysterious places like this:

6 Rage Masters 0x0001625c 0x2a000 + 3003

The process of translating these hexadecimal addresses into method names and line numbers is called symbolic.
A few seconds after capturing the crash log from Xcode's organizer window, the crash log will be automatically symbolized. The following is the symbolic version of the above line: