DSYM file analysis tool and dsym analysis tool

DSYM file analysis tool and dsym analysis tool

After arriving at the new company, I have been busy some time ago. Recently, the project was successfully released and launched. Recently, I have been optimizing the project and eliminating some bugs in online software, because umeng statistics are used in the project, the error information statistics provided by umeng can be used to easily find the client exception information. However, many arrays only provide out-of-bounds information.*** -[_ NSArrayM objectAtIndex:]: index 7 beyond bounds [0 .. 6]'This type of error information is shown in:

If you encounter this problemobjectAtIndexRetrieving errors would be a huge workload.

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./Users/<User Name>/Library/Developer/Xcode/ArchivesDirectory. 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 script compilation ).

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 xx. in the UUID of the app file, run the following command in terminal: dwarfdump -- uuid xx. app/xx (xx represents your project name) 2. view xx. app. the uuid of the dSYM file. In terminal, enter the command: dwarfdump -- uuid xx. app. dSYM 3. the first line of the crash file, Incident Identifier, 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.