DSYM file analysis tool and dsym analysis tool

DSYM file analysis tool and dsym analysis tool

Not long ago, the project was successfully released and launched. Recently, the project was optimized and some bugs in online software were excluded, because umeng statistics were used in the project, therefore, the error information statistics provided by umeng can easily find out the client exception information. However, many errors such as arrays out of the border only provide the ***-[_ NSArrayM objectAtIndex:]: index 50 beyond bounds [0 .. 39] 'this type of error information, as shown in:

In this case, it would be a huge workload to retrieve errors through objectAtIndex.

DSYM File

What is a dSYM file?

After Xcode compiles the project, we will see a dSYM file with the same name. dSYM is a transit file that stores the hex function address ing information. The symbols we debug will be included in this file, A new dSYM file is generated every time you compile the project, which is located in the/Users/<User Name>/Library/Developer/Xcode/Archives directory, for each released version, it is necessary to save the corresponding Archives file (automatically save the dsym files this article describes how to automatically save the dSYM file after each compilation through THE script ).

What is the function of a dSYM file?

When the software release mode is packaged or launched, we will not see the crash error as intuitively in Xcode. At this time, we need to analyze the crash report file, there will be a log file in the iOS device to save the Function Memory Address of each application error. You can use Xcode's Organizer to export DeviceLog from the iOS device to a crash file, at this time, we can query the function name and file name corresponding to the program in the dSYM file through the wrong function address. The premise is that we need a dSYM file corresponding to the software version, which is why it is necessary to save the Archives file for each released version.

How to match files one by one

Every xx. app and xx. app. the dSYM file has the corresponding UUID, and the crash file also has its own UUID. As long as the UUID of the three files is consistent, we can parse the correct error function information through them.

1. view the UUID of the xx. app file. Run the following command in terminal:

Dwarfdump -- uuid xx. app/xx (xx indicates your project name)

2. view the UUID of the xx. app. dSYM file and enter the following command in terminal:

Dwarfdump -- uuid xx. app. dSYM

3. The first line of Incident Identifier in the crash file is the uuid of the crash file.

DSYM Tool

So I spent a few hours encapsulating these commands into an application, which also facilitated the solution of bugs in the future.

Procedure:

1. Drag the xcarchive file when the software is packaged and released to any location in the software window (multiple files can be dragged at the same time. Note: do not include spaces in the file name)

2. Select any version of The xcarchive file. The CPU type supported by the xcarchive file is listed on the right. Select the correct CPU type.

3. Compare the UUID in the error message with the UUID in the tool interface.
4. Enter the error address in the text box of the tool and click analysis.
Mac app project Source Code address

 

 

Link: http://www.cocoachina.com/ios/20141219/10694.html

Reference: http://blog.csdn.net/openglnewbee/article/details/38824139