iOS application crash log uncovered

This article can also find English here

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 Settingsapplication dataapple Computerlogscrashreportermobiledevice

Windows Vista or 7:

C:usersappdataroamingapple Computerlogscrashreportermobiledevice

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 the Window menu from the menu bar and select Organizer (the shortcut is shift-cmd-2).

On the Organizer window, select the Devices tab bar. On the left navigation panel, select Device Logs, as shown in the following illustration:

Look above, there are several Device Logs menu items on the left. The device logs below the LIBRARY 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, select Manage Your applications, click the appropriate application, click the View Details button below the application icon, and then click Crash Reports in the links section of the right column.

If there is no crash log, try clicking the Refresh button to refresh it. 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 Masters Version:??? (???) Code type:arm (Native) Parent PROCESS:LAUNCHD [1] 2: Basic information DATE/TIME:2012-10-17 21:39:06.967-0400 OS Version:ios 6.0 (10a403) version:104 3: Exception Exception type:00000020 Exception codes:0x000000008badf00d Highlighted thread:0 4: Thread Backtracking Thread 0 Name:dispatch Queue:com.apple.main-thread Thread 0: 0 libsystem_kernel.dylib 0x327f2eb4 Mach_msg_trap + 20 1 libsystem_kernel.dylib 0x327f3048 mach_msg + 36 2 corefoundation 0x36bd4040 __cfrunloopservicemachport + 124 3 corefoundation 0x36bd2d9e __cfrunlooprun + 878 4 corefoundation 0x36b45eb8 cfrunlooprunspecific + 352 5 corefoundation 0x36b45d44 Cfrunloopruninmode + 100 6 Cfnetwork 0x32ac343e Cfurlconnectionsendsynchronousrequest + 330 7 Foundation 0x346e69ba +[nsurlconnection SendSynchronousRequest:returningResponse:error:] + 242 8 Rage Masters 0x000d4046 0xd2000 + 8262 Thread 1: 0 libsystem_kernel.dylib 0x32803d98 __workq_kernreturn + 8 1 libsystem_c.dylib 0x3a987cf6 _pthread_workq_return + 14 2 libsystem_c.dylib 0x3a987a12 _pthread_wqthread + 362 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 : 0xFFFFFFFF r5:0x2fd7d301 r6:0x2fd7d300 r7:0x2fd7d9d0 r8:0x2fd7d330 r9:0x3adbf8a8 r10:0x2fd7d308 IP : 0x00000025 sp:0x2fd7d2ec lr:0x001bdb25 pc:0x30301838 cpsr:0x00000010//6: Binary image Binary Images:0xd2000-0xd7fff Age Masters 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/lib System_kernel.dylib 0x328a8000-0x328bdfff libresolv.9.dylib armv7/usr/lib/libresolv.9.dylib 0x32a70000-0x32b35fff Cfnetwork 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-0X32F8AFFFOpenCL 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:

6 Rage Masters 0x0001625c-[rmappdelegate application:didfinishlaunchingwithoptions:] (rmappdelegate.m:35)

Xcode a symbolic crash log, you need to access the. dsym file that is generated when the corresponding binary file is used on the App Store and the binaries are generated. Must match exactly. Otherwise, the log will not be fully symbolic.

Therefore, it is important to keep each compiled version that is distributed to the user. Xcode will save the applied binaries when archiving is submitted before application. All archived application files can be found under the Archives tab of Xcode Organizer.

When a crash log is found, if there is a matching. dsym file and a binary file is applied, Xcode automatically signs the crash log. 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 application binaries and the. dsym file in order for the crash log to be fully symbolic. Every build that is submitted to the itunes connect must be archived.

The. dsym files and binaries are specific to each build and subsequent build, and even from the same source code files, each build is different from the other builds and cannot be replaced by each other.

If you use the build and Archive commands, these files are automatically placed in the appropriate location. If you are not using the build and archive commands, place where spotlight can search, such as the home directory.

Low Memory flash-back

Because the low memory crash log is slightly different from the common crash log, this tutorial is specifically explained separately. :]

When the iOS device detects low memory, the virtual memory system issues a notification request to apply free memory. These notifications are sent to all running applications and processes, trying to reclaim some memory.

If memory usage remains high, the system will terminate the background thread to ease memory pressure. If the available memory is sufficient, the application will continue to run without a crash report. Otherwise, the application will be terminated by iOS and produce a low memory crash report.

There is no stack backtracking for the application thread on the low memory crash log. Instead, the above shows the amount of memory used per process in memory pages. (at the time of writing this article, the size of a memory page is 4KB.) )

You will see the jettisoned word after the name of the process that is terminated by iOS for releasing the memory page. If you see it appearing after your application name, your application is terminated because it uses too much memory.

The low memory crash log looks like this:

Incident identifier:30e46451-53fd-4965-896a-457fc11ad05f crashreporter Key: 5a56599d836c4f867f6eec76afee451bf9ae5f31 os version:iphone os 3.1.3 (7E18) date/time:2012-10-17 21:39:06.967-0400 free pages:96 Wired pages:10558 purgeable pages:0 largest process:rage Masters processes Name UUID Count resident pages Ra GE Masters 9320 (jettisoned) (active) Mediaserverd 255 DATAACCESSD 505 syslogd APSD 171 securityd 243 Notifyd 2027 Comm Center 189 Springboard 2158 (active) accessoryd CONFIGD 371 fairplayd mdnsresponder 292 Lockdownd 1204 Launchd 72

When the application has a low memory flash, you must look at how the memory is used in the application and how to handle the low memory warning. You can use allocations and leaks in the instruments tool to discover memory allocation problems and memory leaks. If you don't know how to use instruments to check for memory problems, take a look at this tutorial.

Also, don't forget the virtual memory. The leaks and allocations of the instruments tool do not track memory usage. You must use VM Tracker to view video memory usage.

VM Tracker is turned off by default. Open instrument, manually select the automatic snapshotting flag or press the snapshot Now button.

Later in this tutorial you will learn how to study the low memory crash log.

Exception encoding

Before studying the real flash-back scenario, there is one more point to focus on: The interesting exception codes.

You can find the exception code in the exception section of the report--part 3rd of the preceding code. Some encodings are more common.

Typically, the exception encoding begins with some text, followed by one or more hexadecimal values, which is where the fundamental nature of the flashback is. From these encodings, you can tell whether the flash is due to program errors, illegal memory access, or other reasons.

Here are some common exception encodings: 0x8badf00d: Read "ate bad food"!  (changing numbers to letters is not much like:p) The code indicates that the application was terminated by iOS due to a watchdog timeout. Typically, the application takes too much time to start, terminate, or apply system events.

0xbad22222: This encoding indicates that VoIP applications were terminated because they were too frequently restarted. 0xdead10cc: Read "dead lock"! This code indicates that the application was terminated because it occupied system resources while running in the background, such as when the Address Book database was not released. 0XDEADFA11: Read "Dead Fall"! The code indicates that the application was forced out by the user. According to the Apple document, force exit occurs when the user presses the switch button until the "slide is turned off" and then the long press the home button. A forced exit produces a crash log that contains the 0XDEADFA11 exception encoding because most of the force exits because the application blocks the interface.

Note: Closing a suspended application in the background task List does not result in a crash log. Once the application is suspended, it is reasonable when it is terminated. So no crash logs are generated.

It's time to show your skill!

All right! You've learned all the basics of analyzing crash logs and fixing bugs!

Let's say you've just entered the Rage-o-rage company. The company has a hot application in the App Store, called Rage Masters.

Your boss Andy wants you to help. Several users often complain about the flash-back problem. Your task is to study these flash-back, symbolic user-supplied crash logs, find out where the problem is, and fix it.

You can download the application source code from here.

Note: If you want to regenerate your crash report yourself, follow these guidelines: Download the source code and open the project file in Xcode. Connect to the iOS device using the correct provisioning profile. Select the iOS device from the Xcode toolbar-not the emulator as target, and then build the application. When you are on the device to the default page (Applied full-screen picture), immediately click the Stop button on the Xcode. Close Xcode. Open the application directly on the device. Test the scene, finish connecting the device to the computer, get the crash log through Xcode.

Scenario 1: Bad code

A message from the user: "Big Brother, your application is a