czm
czm

Reputation: 41

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:

ente  "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/xxx/Downloads/\!dsym-4/demo.app.dSYM/Contents/Resources/DWARF/demo 4333717704

But I can't find the crash stack and the result returned is4333717704

the DSYM file uuid isUUID: 35463E49-9534-3644-B993-2A73C287A143 (arm64) /Users/xxx/Downloads/!dsym-3/demo.app.dSYM/Contents/Resources/DWARF/demo

How should the stack returned by MetricKit be symbolicated?

Upvotes: 4

Views: 1036

Answers (3)

Tom Hamming
Tom Hamming

Reputation: 10981

I asked about this in a WWDC 2024 lab, and atos has a nicer way of doing this now:

atos -i -arch arm64e -o /path/to/symbol/file --offset 1A3B

Where 1A3B is offsetIntoBinaryTextSegment in hexadecimal.

I'm doing this in a Python script to symbolicate MXDiagnostic crash reports here: https://github.com/OliveTreeBible/MXSymbolicate

Upvotes: 0

Mattie
Mattie

Reputation: 3028

Ok, so I'm not at all surprised you're having issues. I think everyone that tries to symbolicate MetricKit data runs into problems.

The reason is the offsetIntoBinaryTextSegment field is incorrectly named. It's actually the binary load address! It took me forever to figure this out. I've filed a bug with Apple, and I suggest you do this same. (though I don't have high hopes, as this JSON structure is effectively an API)

What you want to do is:

atos -arch ARCH -i -l <offsetIntoBinaryTextSegment> /path/to/dsym <address>

Upvotes: 2

YoungForest
YoungForest

Reputation: 311

  1. Use offsetIntoBinaryTextSegment field instead of address. MXCallStackTree explain the meaning of each field. It tells us offsetIntoBinaryTextSegment is the address of symbol. address is the address of stack frame in memory.
  2. Convert 10-base to Hex. atos only accepts Hex address.
  3. atos --help would tell you that two address arguments are needed. loadAddress after -l is your Binary Image load address. address is symbol offset(offsetIntoBinaryTextSegment) + loadAddress. See crash report symbolication. In MXCallStackTree, we do not know Binary Image load address like crash report. But it is not necessary. atos only cares address - loadAddress == offsetIntoBinaryTextSegment. A trick in your situation is loadAddress=0x1 and address=hex(offsetIntoBinaryTextSegment + 1). Therefore, the command line would be, 0x102160000 = hex(4329963520):
atos -arch arm64e -o /Users/xxx/Downloads/!dsym-4/demo.app.dSYM/Contents/Resources/DWARF/demo 0x1 0x102160001

This discussion might help you too: https://developer.apple.com/forums/thread/681967

Upvotes: 1

Related Questions