Error log handling common in IOS development

Outline
How to get crash logs
How to parse the crash log
How to analyze crash logs
1. iOS policy-related
2. Common error identification
3. Code bugs


first, how to get crash log

When an iOS application crashes, the system creates a copy of the crash log on the device. This crash log records information when an application crashes, usually containing stack call information for each thread of execution (with the exception of a low memory flash log), which is helpful for developers to locate the problem.

If the device is on the side, you can connect the device, open the Xcode-window-organizer, select Device Logs in the left panel (you can select device Logs for specific devices or device Logs for all devices under the library), Then look at the crash logs on the device based on the time sort. This is the most frequently used approach in the development and testing phases.

If the application has been submitted to the App Store and the user has already installed it, the developer canvia itunes Connect(Manage Your applications-view details-crash Reports) Gets the Crash log of the user. However, this is not 100% effective, and most developers do not rely on this because it requires the user device to agree to upload the relevant information, details can be found inios:providing Apple with diagnostics and usage informationSummary.

Given that not all iphone users are allowed to automatically send diagnostic reports (crash logs), and for some crash logs submitted to Apple, developers need to pull manually and then find the corresponding symbol file for parsing-This is a tedious task. Therefore, in the actual project development, the existing crash collection tools are usually connected (Reference 1，Reference 2), or write one yourself for automated collection, parsing, and statistical summarization.


second, how to parse crash log

When we get a copy of the crash log, we need to map raw information such as the hexadecimal address of the initial presentation to the source-level method name and the number of lines of code, making it readable to developers. This process is called symbolic parsing. To successfully symbolize a copy of the crash log, we need to have the corresponding application binaries as well as the symbol (. dSYM) file.

If you are in the development debugging phase, it is common for Xcode to match the binary files and symbol files corresponding to the crash log, so it can help us resolve them automatically.

If you are in the testing phase and the testers have installed different versions (such as alpha, beta), then you need to save the corresponding version of the binaries and symbol files to resolve the crash log when the application crashes. For the crash log generated in this scenario, simply place the. crash file, the. app file, and the. dsym file in the same directory, and then drag-and-drop the. Crash file to the Xcode-window- Organizer in the device logs in the left panel library, you can parse it.

If we are going to submit a release, we usually do clean, then build, and finally package through product-archive. In this way, Xcode archives the binaries and symbol files together and can be browsed through the archives in organizer.

Here is a discussion on how to parse the crash log:Http://stackoverflow.com/questions/1460892/symbolicating-iphone-app-crash-reports。


third, how to analyze the crash log

Before analyzing a copy of the crash log, it would be great if the developer had some idea of the common types of errors.
The generation of crash logs comes from two kinds of problems: the violation of iOS policy and the killing of its own code bugs.

1. iOS policy

1.1 Low Memory flash back
As mentioned earlier, most of the crash logs contain stack call information for thread execution, except for low memory flash logs, here's a look at the low memory flash log.
We used the Xcode 5 and iOS 7 devices to simulate a low memory flash, and then view the resulting crash log through organizer, and you can see that both process and type are unknown:



and the specific log content is as follows:



The first part is the crash information, including identification, hardware and software information and time information.
The second part is the memory page allocation information, and the process that currently consumes the most memory, in Crashtypedemo.
The third part is a specific list of processes that describe how each process uses memory and the current state. In earlier versions, you could see the word "jettisoned" behind some processes, indicating that these processes were terminated with too much memory, and now we see the word "vm-pageshortage".

When iOS detects that memory is too low, it (the VM system) emits a low memory warning notification, attempts to reclaim some memory, and if the situation is not improved enough, iOS terminates the background app to reclaim more memory, and finally, if the memory is insufficient, the running app may be terminated.
Therefore, our application should reasonably respond to the low memory warning notifications thrown out by the system, release some cached data and re-created objects, and avoid problems such as memory leaks.

Low memory flash is determined by the iOS policy to terminate the application, and also based on the iOS policy watchdog timeout and user forced exit.

1.2 Watchdog timeout
On Apple's iOS Developer library website,QA1693The watchdog mechanism is described in the documentation, including the effective scenario and performance. If our application does not respond to certain UI events (such as Start, suspend, resume, end), watchdog will kill our application and generate a response crash report.

The interesting part of this crash report is the exception code: "0x8badf00d", or "ate bad food".
If a particular UI event is abstract, then directly described in code, there are several ways to create a uiapplicationdelegate (automatically generated by Xcode when creating a project):



So when you encounter the watchdog log, you can check whether the next few methods have a heavier blocking UI action.

The QA1693 example is to synchronize network requests on the main thread. If we are working in the company's WiFi environment, everything goes well, but when the application is published for a wide range of users, running in various network environments, there will inevitably be a watchdog timeout report.
Another scenario where a problem can occur isdatabase version Migration in the case of large data volumes(also on the main thread), which is a direct factor that prompted me to write this summary.

1.3 User forced exit

Once you see "User forced Exit", you might first think of double-clicking the Home key and then closing the application. However, this scenario does not produce a crash log, because when you double-click the Home key, all applications are in the background, and iOS may close the background process at any time, so this scenario does not have a crash log.

Another scenario is when the user presses the Power key and the home key simultaneously to restart the iphone. This scenario generates a log (verified once only), but is not specific to the application.

This refers to the "user forced exit" scenario, which is a slightly more complex operation: Press and hold the Power key until the "swipe off" interface appears, then press and hold the home button, and the current application is terminated and a crash log of the corresponding event is generated.



Typically, a user should encounter an application that is stuck and affect the iOS response before doing so--but it feels like it's advanced, so the crash log should be rare.

2. Common error Identification

2.1 Exception Codes
The exception codes in the crash log of "user forced exit" above is "0XDEADFA11" and watchdog crash in Exception Log above "codes timeout" is "0x8badf00d", These are unique exception codes.
According to the official document description, there are at least the following specific exception codes:

0X8BADF00D error code: Watchdog timeout, meaning "ate bad food".

0XDEADFA11 error code: User forced to quit, meaning "dead fall".

0xbaaaaaad error code: The user hold down the home and volume keys to get the current memory status, does not represent a crash.



0xbad22222 error code: VoIP applications (because too often?) ) was killed by iOS.

0XC00010FF error code: Because it is too hot to be killed, meaning "cool off."

0xdead10cc error code: Because in the background still occupy system resources (such as Communication Records) was killed, meaning "dead lock".

2.2 Exception Types
Viewing our Crash Analysis report message, you will find that the most common type of error encountered is SEGV (segmentation violation, Segment violation), which indicates improper memory operation, such as access to a memory address that does not have permissions.
When we receivedSIGSEGVSignal, you can consider the following aspects:
Accessing invalid memory addresses, such as accessing zombie objects;
Attempt to write data to the read-only area;
dereference null pointers;
Use an uninitialized pointer;
Stack overflow;
In addition, there are other common signals:
SIGABRT: Receive abort signal, may call abort () or receive external signal sent over;
Sigbus: Bus error. Unlike SIGSEGV, SIGSEGV accesses an invalid address (such as a virtual memory mapping is not physical), and Sigbus accesses a valid address, but bus access exceptions (such as address alignment issues);
Sigill: Attempt to execute an illegal instruction that may not be recognized or has no authority;
Sigfpe:floating point Error, mathematical calculation related problems (may not be limited to floating points calculation), such as except 0 operations;
Sigpipe: No process at the other end of the pipeline takes over data;

3. Code Bugs
In addition, the most common crashes are rooted in code bugs such as array out-of-bounds, intervening spaces, multithreading security, accessing wild pointers, sending selector, and so on. If you introduce core Data, there are some other common problems, but this is another topic.

When encountering these bugs, there is a clear explanation of the cause of the error, such as "Index 0 beyond bounds for empty array" and so on. Need to pay a little attention to the multi-threaded problem, when the moment can not find a solution, you might want to consider the multi-threading

Error log handling common in IOS development