Symbolicating iOS crash address returns inappropriate results

Question

I have spend couple of days lately to learn how to symbolicate a line number of a crash which I receive with a custom solution.

I have figure out I need the .app and .dSYM files, I have checked the UUID and it's the same as the crash that I get, where I also get the UUID to validate.

Three identical UUID and the architecture is arm64, I get the crash to test it from my iPhone5S.

OK, let's say I have in my stacktrace two related to my application lines. Here is the full stacktrace from the JSON I get.

      "0   MyTestApp 0x10000efe8 0x100008000 + 28648",
      "1   UIKit 0x1863d90c8 0x186390000 + 299208",
      "2   UIKit 0x1863d905c 0x186390000 + 299100",
      "3   UIKit 0x1863c2538 0x186390000 + 206136",
      "4   UIKit 0x1863d8a5c 0x186390000 + 297564",
      "5   UIKit 0x1863d86f0 0x186390000 + 296688",
      "6   UIKit 0x1863d3388 0x186390000 + 275336",
      "7   UIKit 0x1863a4b68 0x186390000 + 84840",
      "8   UIKit 0x1863a2c58 0x186390000 + 76888",
      "9   CoreFoundation 0x18339b044 0x1832d0000 + 831556",
      "10  CoreFoundation 0x18339a3a0 0x1832d0000 + 828320",
      "11  CoreFoundation 0x183398638 0x1832d0000 + 820792",
      "12  CoreFoundation 0x1832d96d0 0x1832d0000 + 38608",
      "13  GraphicsServices 0x188fbdc0c 0x188fb0000 + 56332",
      "14  UIKit 0x18640afdc 0x186390000 + 503772",
      "15  MyTestApp 0x10000e4f0 0x100008000 + 25840",
      "16  libdyld.dylib 0x18fed3aa0 0x18fed0000 + 15008"

OK, now I run the atos command in a folder that contains the .app and .dSYM files to try find and symbolicate the memory address.

xcrun atos -arch arm64 -o 'MyTestApp.app'/'MyTestApp' 0x10000efe8

But this line doesn't exactly returns something that I could use.

-[AFHTTPRequestSerializer multipartFormRequestWithMethod:URLString:parameters:constructingBodyWithBlock:error:] (in MyTestApp) (AFURLRequestSerialization.m:317)

I still learning about this process but I believe (in MyTestApp) should be something readable from my test application.

The code I use to crash the application and test how to symbolicate the stacktrace is the following.

113 - (IBAction)logUnhandledException:(UIButton *)sender
114    {
115    void (*nullFunction)() = NULL;
116    nullFunction();
117    }

EDIT: I have the "image_size": "0xa8000" and the "image_base_address": "0x100008000".

Shouldn't I get some information regarding this method and line numbers (if feasible)?

Any help and comments appreciated.

Thank you.

You need the load address for your app binary. Why don't you use an existing crash reporting library that solves all that already? E.g. something based on http://PLCrashReporter.org — Kerni, Mar 27 '14 at 15:31
Thank you for your comment. Actually, I am using the PLCrashReporter, and it's awesome, this is how I get the stacktrace. How does it solves this already? To tell the truth, I'm trying to learn more about symbolication, more ways etc. Any more help about it? How do I get the load address? Or how does PLCrashReporter solves this so I can have the best result of it. — George Taskos, Mar 27 '14 at 15:39
The load address is part of the `Binary Images` section in a crash report. There are plenty of questions and answers on how to symbolicate with the data. Do a search or check the answers I gave loads of times for such questions. PLCrashReporter has a feature to generate a full report at runtime: https://www.plcrashreporter.org/documentation/api/v1.2-rc4/interface_p_l_crash_reporter.html#a5b20583dfbf1f1474315b3b6a7d2fa7e — Kerni, Mar 27 '14 at 15:43
OK I have updated the question with image size and image base address. Does any of these help? Will make a research but I'd love to add an answer to my problem i this thread. OK, I will try the generateLiveReportWithThread method to check on the results and check the image address of the crash report. — George Taskos, Mar 27 '14 at 15:52
I could get some result using the following command. xcrun atos -o MyTestApp.app/MyTestApp -l 0x100008000 0x10000efe8 I have noticed that the load address is the second hexadecimal number in the stacktrace line. And this will result to something like this, although I don't get the line number. Is this valid in your opinion? Is there a way to symbolicate using atos and only the dSYM file? — George Taskos, Apr 01 '14 at 18:38
Simply replace the executable with the dSYM. See http://stackoverflow.com/questions/20364617/atos-gives-lldb-unnamed-function/20364864#20364864 — Kerni, Apr 01 '14 at 22:12

score 4 · Accepted Answer · edited Aug 18 '16 at 00:27

When you want to symbolicate use the load address (the second address, it would be better to always use the image base address of the framework/library but this never changed in my experience so far) after the -l flag and then all the symbol addresses of this framework, the architecture and the corresponding iOS version of the framework you want to symbolicate or if it's your application's line then use the dSYM file, e.g. for the UIKit symbols of the iOS 8.1.1

xcrun atos -arch arm64 -o ~/Library/Developer/Xcode/iOS DeviceSupport/8.1.1 (12B436)/Symbols/System/Library/Frameworks/UIKit.framework/UIKit -l <load_address> <symbols_addressess> ...

For your own application lines

xcrun atos -arch arm64 -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp -l <load_address> <symbols_addressess> ...

And you get all the appropriate results.

Symbolicating iOS crash address returns inappropriate results

1 Answers1

Linked