IOS Crash debugging usage and tips

IOS Crash debugging usage and tips

 

During iOS development and debugging and after launch, the program Often crashes. A simple Crash is better to say that we need to parse the Crash file to analyze the Complicated Crash. parsing the Crash file is quite common in iOS development.

 

There are many blogs on the Internet about Parsing Crash information, but most of them are of varying quality, or some details are not noticed. I wrote a blog today to summarize my usage and skills on crash debugging. If you have any errors or omissions, please give me some advice. Thank you!

Obtain crash information

There are many ways to obtain crash information in iOS. It is common to use third-party analysis tools such as umeng and Baidu, or collect crash information and upload it to the company server. The following lists some common Crash Analysis Methods:

• Use third-party crash statistics tools such as umeng and Baidu.

• Collect application crashes and upload them to the server.

• View the crash information of a device in Xcode-Devices.

• Use the Crash collection service provided by Apple.

  Collect crash information

  Apple provides us with the NSException class for exception handling. This class can create an exception object or obtain an exception object through this class.

  In this class, we usually use a C function to obtain the crash information. We can use this function to collect this exception when an exception occurs in the program.

  1 2 3 4 5 6 7 8 9 10 11 12 13

  // Write the crash information retrieval function provided by the system in this method to ensure that the crash information is obtained when the program starts running. - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions { // Use the function address of the following C function as a parameter NSSetUncaughtExceptionHandler(&UncaughtExceptionHandler); return YES; } // Set a C function to receive crash information void UncaughtExceptionHandler(NSException *exception){ // Some crash information can be obtained through the exception object, which is parsed. For example, the symbols array below is our crash stack. NSArray *symbols = [exception callStackSymbols]; NSString *reason = [exception reason]; NSString *name = [exception name]; }

  We can also use the following method to obtain the function pointer of the crash statistics:

  1	NSUncaughtExceptionHandler *handler = NSGetUncaughtExceptionHandler();

  DSYM symbolic set

  For crash analysis, you must first understand the concept of a symbolic set.

  • The symbolic set is a file with the same suffix as. dSYM as the. app file after we pack the ipa file. This file must be packaged using Xcode.

  • Each. dSYM file has a UUID, which corresponds to the uuid in the. app file, representing an application. Each crash message in the. dSYM file also has a separate UUID, which is used to verify the UUID of the program.

  • If we do not use the. dSYM file, the crash information is inaccurate.

  • Symbols store information about file names, method names, and row numbers in a centralized manner. They correspond to the hexadecimal function addresses of executable files and crash through analysis. the Crash file can accurately know the specific Crash information.

    Every time we Archive a package, we will generate a dSYM file. Every time we release a version, we need to back up this file to facilitate future debugging. When the crash information is symbolic, The dSYM file generated by the computer packaged by the current application must be used. Files generated by other computers may cause inaccurate analysis.

    Archive

    When the program crashes, we can get the crashed error stack, but this error stack is a hexadecimal address starting with 0x. We need to use the symbolicatecrash tool that comes with Xcode. crash and. the dSYM file is symbolic to obtain detailed crash information.

    Crash Analysis

    Parse the Crash file using the command line

    Daily Updates: http://weibo.com/hanjunqiang Sina Weibo

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

    • Symbolicatecrash is a crash analysis tool that comes with Xcode. This tool can be used to locate the crash more accurately and replace the address starting with 0x with the response code and the number of lines.

    • The dSYM file generated during packaging.

    • Crash files generated during Crash.

      When parsing the Crash information, I first create a Crash folder on the desktop, and then. crash ,. dSYM and symbolicatecrash are placed in this folder. In this way, enter the folder and run a line of command to solve the problem.

      We can find the symbolicatecrash in the following path. I use Xcode7. The paths for Xcode of other versions are different. please Google it on your own.

      1	/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash

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

      DSYM File

      Put the. Crash,. dSYM, and symbolicatecrash files in the Crash folder created on the desktop.

      Crash folder

      Enable the command line tool to enter the collapsed folder

      Cd/Users/username/Desktop/crash folder

      Use commands to parse Crash files

      ./Symbolicatecrash./*. crash./*. app. dSYM> symbol. crash

      If the preceding command fails, run the command to check the environment variables.

      Xcode-select-print-path

      Returned results:

      /Applications/Xcode. app/Contents/Developer/

      If it is not the preceding result, you need to use the following command to set the exported environment variable and repeat the above parsing operation.

      Export cmd_dir =/Applications/XCode. app/Contents/Developer

      After parsing, a new. Crash file is generated, which contains the detailed Crash information. The red part in the figure is part of the code crash.

      Resolution result

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

      • Memory Access Error (not a wild pointer error)

      • Low memory. When the program memory usage is too large, the system will cause low memory problems, and the system will recycle the program memory.

      • Triggering the watchdog mechanism for some reason

        View device crash information through Xcode

        In addition to the above system analysis tools for analysis, if we directly use the phone connection to crash or crash and connect to the phone, choose window> devices> your mobile phone> view device logs to view the crash information.

        View device logs

        As long as the application on the mobile phone is installed and packaged on this computer, such a crash information system has become symbolic for us, we only need to wait for a while (do not trust the progress here to refresh, (Not accurate). If the symbols are not completed, select the file and right-click Re-Sysbomlicate.

        For packaging on other computers, we can export the Crash file and parse it by using the command line.

        Daily Updates: http://weibo.com/hanjunqiang Sina Weibo

        Use third-party crash analysis tools

        Currently, many third-party tools can perform crash statistics and analysis. umeng crash statistics are mostly used. umeng crash statistics are integrated into umeng sdks, the specific usage is the best way to go directly to the official documentation. The following lists the URL of the umeng crash statistics documentation.

        Umeng crash statistics official documentation

        Here, I do not recommend umeng as a third party, but a better third-party-bugHD. The biggest difference between this third-party and umeng is that it can directly analyze the crash information in combination with dSYM and display it on the web page. It can also count the number of crashes, crashed devices, and system versions.

        The following are some crashes in my company's bugHD statistics.

        BugHD

        The bugHD server has helped us use dSYM to complete the symbolic crash. We can click a crash to view the detailed crash stack, as well as the crash device distribution and system distribution.

        Detailed distribution

        Crash statistics tool provided by Apple

        Apple integrated crash statistics for us in Xcode, which can be seen in Window-> Organizer-> Crashes

        Crashes

        Crash statistics tools provided by Apple are not recommended. If you want to use this function, you need to set it on the iPhone.

        Settings-> privacy-> diagnosis and usage data (iOS8 is set in general)

        Select Automatic sending and share it with developers.

        Malicious third-party tool coverage

        The crash collection statistics function should be called only once. If a third party is used, it is better to use only one third party. In this way, we obtain the crash statistics only.

        Third-party statistical tools are not used as much as possible. Using multiple crashes to collect third-party data may cause malicious coverage of NSSetUncaughtExceptionHandler () function pointers, and some third parties may not receive crash information.

        Currently, many third-party crash collection tools will maliciously overwrite NSSetUncaughtExceptionHandler () function pointers to ensure that they can collect crash information as much as possible. Because this function transmits the function address as a parameter, it will be overwritten as long as repeated calls are made, so the stability of the crash collection cannot be guaranteed.

        When parsing the crash information, we can see that the crash stack is only main. m file crash, and can be determined not because of main. the crash caused by a bug in the m file can basically be determined that the NSSetUncaughtExceptionHandler () function pointer is maliciously overwritten.

        Crash stacks maliciously covered