MetricKit MXCallStackTree symbolication

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

Replies

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.

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.

  • Thank you for your reply .I tried as you said `atos -arch arm64 -o /Users/***/Downloads/!dsym-4/demo.app.dSYM/Contents/Resources/DWARF/demo -l 0x102160000 0x1024F48C8

    thunk for @escaping @callee_guaranteed (@unowned Int) -> () (in MTXX) (😮 )`

    The architecture in Metrickic's log is ARM64E "diagnosticMetaData": { "appBuildVersion": "35532.1", "appVersion": "9.1.80", "regionFormat": "CN", "exceptionType": 13, "osVersion": "iPhone OS 14.0 (18A373)", "deviceType": "iPhone11,8", "signal": 9, "exceptionCode": 0, "platformArchitecture": "arm64e", "terminationReason": "SPRINGBOARD, <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-create watchdog transgression: application<com.meitu.mtxx>:879 exhausted real (wall clock) time allowance of 10.00 seconds | ProcessVisibility: Background | ProcessState: Running | WatchdogEvent: scene-create | WatchdogVisibility: Foreground | WatchdogCPUStatistics: ( | \"Elapsed total CPU time (seconds): 17.350 (user 17.350, system 0.000), 29% CPU\", | \"Elapsed application CPU time (seconds): 10.098, 17% CPU\" | ) reportType:CrashLog maxTerminationResistance:Interactive>" }

  • I adjusted my answer here with an adjusted command to help you. Please give that a try and let me know if it helps you get a valid symbol.

    On the CPU architecture, platformArchitecture is reporting that the CPU for this device uses the arm64e architecture, not that your app binary is arm64e.

  • I tried as you said. atos -arch arm64 -o /Users/xxxx/Downloads/\!dsym-4/demo.app.dSYM/Contents/Resources/DWARF/demo -l 0x1 0x102160001 However, the parser did not successfully return 0x102160001

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>

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