This article belongs to < Jane books – = “” Liu Xiaozhuang =” “> original, reproduced please indicate: < Jane books – Liu Xiaozhuang =” “> http://www.jianshu.com/p/77660e626874

During iOS development and debugging and after launch, programs often crash. Simple crashes are easy, but complex crashes need to be analyzed by parsing Crash files. Parsing Crash files is relatively common in iOS development. There are many blogs on the web about parsing crash information, but most are of uneven quality, or some details are not noticed. Today write a blog to summarize my use of crash debugging and skills, if there are any mistakes or omissions, please also give advice, thank you!

Getting crash information

There are many ways to obtain crash information in iOS. The most common ones are to use third-party analysis tools such as Umeng and Baidu, or to collect crash information and upload it to the company server. Here are some common ways to analyze crashes:

  • Use third-party crash statistics tools such as Umeng and Baidu.
  • Do your own in-app crash collection and upload it to the server.
  • Xcode-Devices directly displays the crash information of a device.
  • Use the Crash collection service provided by Apple.

Collecting Crash Information

Apple provides us with an exception handling class, NSException. This class can create an exception object, and it can get an exception object from this class. The most commonly used C function in this class is a crash information C function that can be used to collect exceptions when they occur in the program.

// Write the function provided by the system to get crash information in this method, To ensure that the program starts running will have the function of the collapse of information - (BOOL) application: (UIApplication *) application didFinishLaunchingWithOptions: (NSDictionary *) launchOptions {/ / the following C function function addresses as parameter NSSetUncaughtExceptionHandler (& UncaughtExceptionHandler); return YES; } void UncaughtExceptionHandler(NSException *exception){ We use this crash information to parse, for example, the following symbols array is our crash stack. NSArray *symbols = [exception callStackSymbols]; NSString *reason = [exception reason]; NSString *name = [exception name]; }Copy the code

We can also get a function pointer to crash statistics by:

  NSUncaughtExceptionHandler *handler = NSGetUncaughtExceptionHandler();Copy the code

DSYM symbol set

The first thing you need to understand in crash analysis is the symbol set.

  • The symbol set is the.dsym file that we packaged with the IPA file, the same as the.app file, and that file has to be packaged with Xcode.
  • Each.dsym file has a UUID that corresponds to the UUID in the.app file, which represents an application. Each crash message in the.dsym file also has a separate UUID, which is checked against the UUID of the program.
  • If we do not use the.dsym file to get crash information is not accurate.
  • The symbol set stores information about file names, method names, and line numbers, which correspond to the hexadecimal function addresses of executable files, and is broken by analysis. The Crash file can know exactly what Crash information is.

Each time we Archive a package, a dSYM file is generated. We need to back up this file every time we release a version to facilitate future debugging. When symbolizing crash information, you must use dSYM files generated by the current application package computer. Files generated by other computers may cause problems with inaccurate analysis.




Archive

When an application crashes, we can get a crash error stack, but the error stack is a hexadecimal address starting with 0x, which requires us to use Xcode’s symbolicatecrash tool. The Crash and.dsym files are symbolized to get detailed Crash information.

Collapse analysis

Parse the Crash file

Three files are required to parse the Crash file using the Mac command line tool

  • Symbolicatecrash — Xcode’s own crash analysis tool that allows you to pinpoint the crash location more precisely, replacing the address beginning with 0x with the code and line number of the response.
  • DSYM files generated when we pack.
  • A Crash file generated during a Crash.

When I parse the Crash information, I first create a Crash folder on my desktop, and then I will. Crash,.dsym, and Symbolicatecrash are placed in this folder so that entering this folder can be solved with a single command.

Symbolicatecrash we can find it in the path below, I use Xcode7, other versions of Xcode path is not the same, please Google.

/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrashCopy the code

Then in Window->Organizer->Archives, right-click the archive version and select Show in Finder to get the dSYM file.




DSYM file

Put the.crash,.dsym, and Symbolicatecrash files in the Crash folder we created on the desktop.




Crash folder

Start the cli tool and go to the crash folder CD /Users/username/Desktop/ crash folder

Parse the Crash file./symbolicatecrash./*.crash./*.app.dsym > symbol.crash

If the above command is not successful, use the command to check the environment variable xcode – select – print – the path to return the result: / Applications/xcode. The app/Contents/Developer /

If not, use the following command to set the exported environment variable, and then repeat the above parsing. Export DEVELOPER_DIR = / Applications/XCode. App/Contents/Developer will generate a new after parsing is complete. Crash file, which contains Crash details. The part highlighted in red is the part where our code broke.




Parse the finished results

Note that no crash message is generated in the following cases:

  • Memory access error (not wild pointer error)
  • Low memory. When a program uses too much memory, the system reclaims the program memory
  • Trigger watchdog mechanism for some reason
View device crash information using Xcode

In addition to the above system analysis tools for analysis, if we directly use the phone connection crash or after the crash to connect to the phone, choose Window -> Devices -> select your phone -> View Device Logs to view our crash information.




view device logs

As long as a mobile phone application is packaged, install the computer so the collapse of the information system has been symbolization is good for us, we just need to go in just a moment, don’t believe this refresh, the schedule is not accurate), if there is still no symbolic, we select the file, then right-click to choose Re – Sysbomlicate can.

If you are using other computers for packaging, we can export the Crash file here and parse it ourselves through the command line.

Use third-party crash analysis tools

Now there are a lot of third-party tools can be used for crash statistics analysis, the most commonly used is UmENG crash statistics, umeng crash statistics is integrated in the SDK, the specific use of direct access to the official document is the best method, listed below the umeng crash statistics document address. Friendly alliance crash statistics official documentation

I don’t recommend Umeng as a third party, but a more useful third party — bugHD. The biggest difference between this third party and UmON is that it can directly analyze the crash information in combination with dSYM and display it on the Web page, and it can also count the number of crashes, crashed devices and system versions.

Here are some of the crashes my company counted using bugHD




bugHD

The bugHD server has helped us symbolize the crash using dSYM. We can click on a crash to see the detailed crash stack, as well as the crash device distribution and system distribution.




The detailed distribution of

Apple has its own crash statistics tool

Apple has integrated crash statistics for us in Xcode, as you can see in Window->Organizer->Crashes




Crashes

Apple’s built-in crash statistics tool is not recommended. If you want to use this feature, you need to go to Settings – Privacy -> Diagnostics & Usage -> Diagnostics & Usage data (iOS8 is set in General below) on your iPhone and select auto send and share it with developers

Third-party tools malicious overwrite

The crash collection statistics function should be called only once, and preferably only once if a third party is used, so that we have a unique way to get crash statistics. Third-party statistical tools is not used, the more the better, the use of multiple collapse to collect the third party will cause NSSetUncaughtExceptionHandler () function pointer malicious coverage, crash some third party cannot receive information. Now a lot of collapse of the third party collection tool in order to ensure that they can collapse to collect information as much as possible, to NSSetUncaughtExceptionHandler malicious coverage () function pointer. Because this function is passed the function address as an argument, repeated calls will be overridden, which cannot guarantee the stability of crash collection.

Collapse collapse parsing information, we see only the main stack. The collapse of m file, and not because the main can be determined. In the m file bugs caused by collapse, is basic can determine NSSetUncaughtExceptionHandler () function pointer is covered by a malicious.




A crash stack that was maliciously overwritten