iOS Crash log analysis

1. Causes of crash log analysis

In the actual development, we may often encounter the program crashes, but sometimes it is difficult to reproduce the crash situation, or we upload to AppStore , the program may crash, this time will lead to user dissatisfaction with the program, However, we can not ask the user to reproduce his operation steps, the crash problem can not be effectively resolved, or the tester to detect the program crashes, but the developers for a variety of reasons can not be very good to reproduce the problem of the crash. In cases where these cannot be reproduced, we can look at the crashreport, which is a good solution to the name of the function and the module name and the number of crashes that are recorded in the program crash. We only need to follow the parsed log can be directly to the crash of the place to debug, can be a program crash where there is a good solution.

2. Classification of crash logs

1, the application exits (generally refers to the normal operation of the user program caused by abnormal exit).

2, low memory, when the application's memory trial reaches a certain level, will issue a memory warning, such as

The memory continues to increase and the memory usage is limited.

Application.

3, the user forced to quit the program

4, Watchdogtimeout: Through a timer to see if an event has exceeded the expected time

The most important reason to tell the OS to end the program, if yes

For Synchronous HTTP request causes the entire picture to be immobile and unresponsive .

3. How to parse the crash log

1, get crashreport, different platform to get the log directory is not the same.

Mac os directory: ~/library/logs/crashreporter/mobiledevice/

Xp:c:\documents and\<username>\application data\

Apple computer\logs\crashreporter\mobiledevice\<device_name>

Windows Vista or 7:c:\users\<username>\appdata\roaming\applecomputer\logs

\crashreporter\mobiledevice\<device_name>

2 After opening the view is just some 16 The address of the system, We are unable to get useful information, this time we only need to see the crash log inside the uuid, xcode crashreport, find binary images: uuid.

3, open the terminal, run the command:dwarfdump--uuid/usr/crash/ihexin.app/ihexin ( Front plus the path to change the file ) View the UUID of the package .

4, Same (3), Run command:dwarfdump--uuid/usr/crash/ihexin.app.dsym View UUID.

5, in the above step (2,3,4) of the three UUID the same situation Can parse the crash log. Run command:symbolicatecrash/usr/crash/ihexin.crash/usr/crash/ihexin.app.dsym >/usr/crash/xxxxx_symbol.crash .

6, step 5 ,xxxxx_symbol.crash is the parsed crash log, you can view the crashed thread and the stack. The collapsed function is then debugged based on the stack's information.

Also: Crash logs can be parsed in XOCDE , but I didn't try to succeed. You can see

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

Note: (1)the position of Symbolicatecrash in xcode4 is:
/developer/platforms/iphoneos.platform/developer/library/privateframeworks/dtdevicekit.framework/versions/a/ Resources/symbolicatecrash
(You can copy the symbolicatecrash program to /usr/bin and you can call it directly from the command line )

(2). DSYM files and . App files must be placed where Spotlight can find them , at the same time, you must ensure that the log will be parsed . DSYM and the . App file and the resulting log file. app and the . DSYM the file version is consistent, otherwise it must not be resolved.

iOS Crash log analysis