1

I tried finding the method name from a .crash file using "atos" command line utility, but getting wrong method names. Ex: crash log says exception is due to sending message to UIComponent unrecognized selector sent to intense but after symbolicating "atos" showing a method in network related class.

As suggested here iOS crash reports: atos not working as expected tried looking at the "Slide & LoadAddress" in my case these both are same (Slide: 0x4000 LoadAdress: 0x4000).

And also I verified the .iPA file that I am using is the correct as suggested here: https://developer.apple.com/library/mac/qa/qa1765/_index.html.

I am not sure whats going wrong. Could any one faced the same issue? Please suggest any other approaches.

I have a .iPA file and .crash file, need to find out correct method names.

Here is the full crash report:

http://www.filedropper.com/symbolicate

Command to find out the .iPA is the correct one:

dwarfdump --uuid Example.app/Example

Command to find out the method name:

atos -arch armv7 -o Example.app/Example -l 0x4000 0x7f68bb0 0x3017d000 + 84904

which is giving a method in network class where I don't have any UIComponent.

Please let me know if you need more details.

Thanks Shiva.

Community
  • 1
  • 1
Shiva Reddy
  • 456
  • 1
  • 7
  • 26

1 Answers1

1

There are multiple things:

  1. The crash is caused by an exception and the crash report does not show the required Last Exception Backtrace.

  2. Symbolicating the main thread will only show you the main.m call in frame 12 and the uncaught exception handler in frame 2 of thread 0

  3. The crash report is written by an old version of PLCrashReporter (identified by the two [TODO] texts on top) or you are using another server for uncaught exceptions. As is, the crash report will not help you.

  4. You should use atos with the apps dSYM instead of the app binary. Using the app binary will never show you filenames or line numbers and will only show you class name and methods if you don't strip symbols from the executable. But you should strip them from the executable to keep the binary size as low as possible (saves 30-50%).

  5. The way you are calling atos is wrong. 0x7f68bb0 0x3017d000 + 84904 is not a valid option, and in fact your crash report doesn't even contain that. Instead you need to use only the first address after the binary name per frame. So for the following line:

     2   Example                               0x001ffe3b 0x4000 + 2080315
    

    You would use atos as follows:

     `atos -arch armv7 -l 0x4000 -o Example.app.dSYM 0x001ffe3b`
    

You should update your crash reporting SDK to use the latest PLCrashReporter version and make sure exceptions are shown properly in the report.

junjie
  • 7,946
  • 2
  • 26
  • 26
Kerni
  • 15,241
  • 5
  • 36
  • 57
  • Thanks a lot Kerni for your time and detailed explanation. – Shiva Reddy Nov 11 '14 at 01:42
  • 3. Will update the PLCrashReporter. 4. I haven't stripped the symbols during archiving the App Store build, was able to get the class and method names. The problem is the names it has given are wrong as mentioned in my question. 5. The address is samples not the original which I used while running atos. Could you please let me know how to point to the .dSYM file from .iPA? because when I run atos -arch armv7 -l 0x4000 -o Example.app.dSYM 0x001ffe3b, getting "atos cannot load symbols for the file Burst.app.dSYM for architecture armv7" – Shiva Reddy Nov 11 '14 at 01:52
  • The ,dSYM and original .app are in your Xcode archive that you used to create the .ipa. Open the Xcode organizer to get that and its path. – Kerni Nov 11 '14 at 11:34
  • Ok. Thank you. Is there any specific reason why its giving me wrong method names even after comparing (found that they are correct) the .iPA file UUID and also load address with slide? – Shiva Reddy Nov 11 '14 at 12:17
  • Most likely you are calling atos wrong or the file is not the correct one. Without having the actual file, corresponding crash report and the exact atos call you are doing, it is impossible to say. – Kerni Nov 11 '14 at 13:25