After I came to the new company, I have been busy some time ago. Not long ago, the project was finally successfully released online. Recently, I have been optimizing the project and eliminating some online software bugs. Because the Umeng statistics are used in the project, it is The error information statistics provided by Umeng can easily find out the information of client exceptions, but many things like array out of bounds only give *** -[__NSArrayM objectAtIndex:]: index 50 beyond bounds [0 .. 39 ]' This kind of error message, as shown in the following figure:
Encountering this problem, it will be a huge amount of work to retrieve the wrong place 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 transfer file that saves the hexadecimal function address mapping information. The symbols we debug will be included in this file, and a project will be generated every time we compile the project. The new dSYM file is located in the /Users/<username>/Library/Developer/Xcode/Archives directory. For each release, it is necessary to save the corresponding Archives file ( AUTOMATICALLY SAVE THE DSYM FILES This article introduces The dSYM file is automatically saved after each compilation via the script).
What a dSYM file does
When our software is packaged or launched in release mode, we will not see the crash error as intuitively as we did in Xcode. At this time, we need to analyze the crash report file. There will be log files in the iOS device to save each of our applications. For the memory address of the wrong function, the DeviceLog in the iOS device can be exported as a crash file through the Organizer of Xcode. At this time, we can query the function name and file name corresponding to the program in the dSYM file through the address of the wrong function. The main premise is that we need to have the dSYM file corresponding to the software version, which is why it is necessary for us to save the Archives file of each release version.
How to match files one by one
Each xx.app and xx.app.dSYM file has a corresponding UUID, and the crash file also has its own UUID. As long as the UUIDs of these three files are the same, we can parse out the correct error function information through them.
1. View the UUID of the xx.app file and enter the command in the terminal:
dwarfdump --uuid xx.app/xx (xx represents your project name)
2. View the UUID of the xx.app.dSYM file and enter the command in the terminal:
dwarfdump --uuid xx.app.dSYM
3. The first line of Incident Identifier in the crash file is the UUID of the crash file.
dSYMtools
So I took a few hours to encapsulate these commands into an application, which also provides convenience for troubleshooting bugs later.
Steps for usage:
1. Drag the xcarchive file when the software is packaged and released into any position in the software window (support for multiple files to be dragged in at the same time, note: the file name should not contain spaces)
2. Select any version of the xcarchive file, the CPU type supported by the xcarchive file will be listed on the right, and the CPU type corresponding to the error will be selected.
3. Compare whether the UUID given by the error is consistent with the UUID given in the tool interface.
4. Enter the error address into the text box of the tool and click Analyze.
Mac app p download address project source code address
