iOS crash reports: atos not working as expected

George Burdell picture George Burdell · Nov 27, 2012 · Viewed 29.7k times · Source

I'm looking at a crash report provided by Apple

Hardware Model:      iPhone4,1
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2012-11-18 16:03:44.951 -0600
OS Version:      iOS 6.0.1 (10A523)
Report Version:  104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x51fe5264
Crashed Thread:  0

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0   libobjc.A.dylib                 0x352925b0 objc_msgSend + 16
1   MYAPP                           0x0006573a -[MyViewController(Images) didReceiveImage:context:etag:expires:] + 42
2   MYAPP                           0x0004fb26 -[MyImageTask didReceiveImage:] + 98
3   Foundation                      0x361ac8e8 __NSThreadPerformPerform
4   CoreFoundation                  0x3b37d680 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
5   CoreFoundation                  0x3b37cee4 __CFRunLoopDoSources0
6   CoreFoundation                  0x3b37bcb2 __CFRunLoopRun
7   CoreFoundation                  0x3b2eeeb8 CFRunLoopRunSpecific
8   CoreFoundation                  0x3b2eed44 CFRunLoopRunInMode
9   GraphicsServices                0x396bc2e6 GSEventRunModal
10  UIKit                           0x3452e2f4 UIApplicationMain
11  MYAPP                           0x0004934a main + 70
12  MYAPP                           0x000492fc start + 36

The funny thing is when I use atos to lookup the line of code that corresponds to address locations 0x0006573a and 0x0004fb26 I get completely different match. The atos output is not even from the same class that's mentioned in the crash log (MyViewController, MyImageTask). Instead atos points me to totally benign lines of code in a completely unrelated class. I verified again that I'm working with the exact dSYM and IPA that I submitted to Apple.

My atos command

/Applications/Xcode.app/Contents/Developer/usr/bin/atos -arch armv7 -o MYAPP.app/MYAPP 0x0004fb26

Same result with /usr/bin/atos and for armv7s.

Has anyone else experienced this issue? Can you please advise? Thanks.

Answer

Chris picture Chris · Oct 10, 2013

A simpler alternative: you can use the atos -l flag to make it do the maths for you.

Say you've got the following line in your crash log that you want to symbolicate:

5   MyApp                   0x0044e89a 0x29000 + 4348058

The first hex number is the stack address, and the second hex number is the load address. You can ignore the last number. You don't need to worry about slide addresses either.

To symbolicate, do the following:

atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a

If you can't find your MyApp.app/MyApp file, rename your '.ipa' file to a '.zip', unzip it, and it'll be in the Payload folder.

And if you're not sure which architecture to use (for example, armv7 or armv7s), scroll to the 'Binary Images' part of the crash file and you can find it in there.

Cheers