macOS uses the atos command to parse arbitrary crash records and sample data

Recently, the drop grid input method has encountered several difficult to reproduce problems-the key is that it will not cause a crash。This makes the crash statistics function completely ineffective，The specific performance is that the input method will suddenly get stuck for a few seconds in some cases，Very annoying。Then I thought，macOS comes with activity manager，There is a "sampling" function，You can see the current execution (call) status of the corresponding process，Can I use it to analyze the cause of the error?

After communicating with users，I got a sampling report like this：

After executing the code of my program，I got to the stuck place soon，Obviously，It should be an API I called that triggered a system bug or something，So as long as I can find out where it is called，What was called，It should be easy to locate the problem，Specific to this example，It is 1774 ??? (in LogInputMac2) What does it represent。

So look at the address behind，I guess it should be similar to the crash log，It also needs dSym to resolve，Only this time there is no ready-made function to use，We need to manually calculate this address (of course, just manually call the lower level tool，Real hands are still unnecessary)

acts

The atos command comes with Xcode，Various tools we use to automatically parse crash logs，Build on top of it，So the first step，We first find the corresponding dSym file (hope you can find it)。

After getting the file，We use the command to parse its uuid，Must be consistent with the results in the sampled data：

Below the sampled data，Binary image，This shows the version of your program and its uuid。After finding the corresponding dSym，We use the command xcrun dwarfdump --uuid LogInputMac2.app.dSYM/Contents/Resources/DWARF/LogInputMac2 To view the architecture and corresponding uuid contained in dSym，For example, mine is：

You see，Corresponding to the sample is the one of x86_64。

Then we enter the interactive mode of atos，First find the start point of the virtual address of your program，For example, in this line 2713 ??? (in LogInputMac2) load address 0x102d32000 + 0x22aa3 [0x102d54aa3] My starting point is 0x102d32000 You will find in other lines，The starting point is the same，Only the address behind is different，After getting this starting point，We execute the order：

At this time, the terminal enters the prompt state，Show nothing inside，Then we can enter the actual address for conversion，Or the line 2713，The address in square brackets at the end is the actual address where the program runs，We enter it，atos will display the corresponding code according to your dSym file。

Because it's interactive mode，You can continue to enter other addresses，No need to repeat commands：

References

• Resolving symbols in a sample log from Activity Monitor
• Analysis of crash log (1)

Original article written by Gerber drop-off：R0uter's Blog » macOS uses the atos command to parse arbitrary crash records and sample data

Reproduced Please keep the source and description link：https://www.logcg.com/archives/3475.html