Reputation: 41
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
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
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
Reputation: 311
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.atos
only accepts Hex address.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