MetricKit MXCallStackTree symbolication

Question

Created Jun ’21

Replies 3

Boosts 0

Views 2.8k

Participants 4

I am trying to implement MetricKit so later I could analyze MXCrashDiagnostic and MXHangDiagnostic reports. However when I am triggering a test crash, Here is an example of what I get for MXCrashDiagnostic:

iente "timeStampEnd": "2021-06-07 15:59:00 +0000", "crashDiagnostics": [ { "version": "1.0.0", "callStackTree": { "callStacks": [ { "threadAttributed": true, "callStackRootFrames": [ { "binaryUUID": "DC2EACEA-3D9C-3409-96C2-2DF9C89AD19D", "offsetIntoBinaryTextSegment": 6917586944, "sampleCount": 1, "subFrames": [ { "binaryUUID": "DC2EACEA-3D9C-3409-96C2-2DF9C89AD19D", "offsetIntoBinaryTextSegment": 6917586944, "sampleCount": 1, "subFrames": [ { "binaryUUID": "DC2EACEA-3D9C-3409-96C2-2DF9C89AD19D", "offsetIntoBinaryTextSegment": 6917586944, "sampleCount": 1, "subFrames": [ { "binaryUUID": "35463E49-9534-3644-B993-2A73C287A143", "offsetIntoBinaryTextSegment": 4329963520, "sampleCount": 1, "binaryName": "demo", "address": 4333717704 }]

I tried to symbolicate the the data, by executing commands: atos -arch arm64e -o /Users/***/Downloads/!dsym-4/demo.app.dSYM/Contents/Resources/DWARF/demo 4333717704

But I can't find the crash stack and the result returned is 4333717704 the DSYM file uuid is UUID: 35463E49-9534-3644-B993-2A73C287A143 (arm64) /Users/***/Downloads/!dsym-3/demo.app.dSYM/Contents/Resources/DWARF/demo

How should the stack returned by MetrickIt be symbolized? Who can tell me very grateful

Boost

Answer 1

DTS Engineer OP

Apple

Jun ’21

There's three things you need to do. First, you need to convert the decimal offsetIntoBinaryTextSegment address to hex. This is the exact instruction your app was executing when it crashed, expressed as an instruction offset from the start of the binary. You can do this in the Calculator app, using the Programmer view. Use the 10 and 16 buttons to convert between decimal and hex.

Screen Shot 2021-06-10 at 5.28.29 PM.jpg

Second, you need to adjust this value by adding 0x1 to it. So, in this example, 0x102160000 becomes 0x102160001. This is because we don't know the binary load address, or the slide the OS used when loading the binary into memory. By adding 0x1, that lets us use the atos -l option to apply an invented slide for ease of symbolication without needing to use other tools to determine the right addresses we need for symbolication.

Third, confirm the architecture. arm64e is only supported for system frameworks, and not any binaries provided by your app. I suspect you want arm64 instead.

With these pieces of info, your atos command becomes: % atos -arch arm64 -o <filePath> -l 0x1 0x102160001

Give that a try and let me know if you get the symbol info you're expecting.

2

Answer 2

noooodle OP

Nov ’21

I also encountered the same problem, after I trying this way and get the close symbols:

atos -arch <ARCH> -o <PATH TO DYSM> -l <hex offsetIntoBinaryTextSegment> <hex address>

0

Answer 3

Mr. Jefferson OP

Dec ’23

Based in part on this thread, I've implemented symbolication of these diagnostic reports in a python script: https://github.com/OliveTreeBible/MXSymbolicate

0