iOS crash reports: atos not working as expected

Question

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.

Ruthanneruthe

Answer 1

You have to calculate the address to use with atos, you can't just use the one in the stacktrace.

symbol address = slide + stack address - load address

1. The slide value is the value of vmaddr in LC_SEGMENT cmd (Mostly this is 0x1000). Run the following to get it:

   otool -arch ARCHITECTURE -l "APP_BUNDLE/APP_EXECUTABLE" | grep -B 3 -A 8 -m 2 "__TEXT"
   

   Replace ARCHITECTURE with the actual architecture the crash report shows, e.g. armv7. Replace APP_BUNDLE/APP_EXECUTABLE with the path to the actual executable.

2. The stack address is the hex value from the crash report.

3. The load address can be is the first address showing in the Binary Images section at the very front of the line which contains your executable. (Usually the first entry).

Since in the past value of the slide was equal to value of the load address this always worked. But since Apple introduced Address space layout randomization beginning with iOS 4.3 (in different variations), the apps loading address is randomized for security reasons.

Phallic

But I didn't get the 3rd point completely. Would be great if you can mention from where I can locate the Binary Images section. – Quarto

Silly me, load address can be found inside the crash report itself,Binary Images: 0x79000 - 0x206fff +MyApp armv7 <80b56c4fbede355288cf5faa80ab7827> /var/mobile/Applications/0709EF90-2F23-4220-AB2E-48BA4C983C9A/MyApp.app/MyApp – Quarto

can you give a example tell my how to use symbol address = slide + stack address - load address. i cannot understand it – Bedraggle

Or you could just use atos -l and let it do the math for you. I'm also pretty sure that "slide" refers to the difference between the nominal and actual load address, not the load address itself. – Nemeth

You sir ROCK! Thank you so much! Just up voted several of your answers! – Freckly

I'm getting a negative value for symbol address, using your calculation. Is something horribly wrong? – Stray

@TimArnold Well, if the crash reports are already symbolicated, then the addresses are already normalised by the symbolication script from Xcode. So check if stack address > load address and that your are really checking the correct element under the binary images section. – Phallic

What would be the problem you think if you have a problem with atos not symbolicating correctly any symbol address than your own application? #26079556 – Hartzke

Answer 2

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

Uncertainty

I was having a lot of trouble symbolicating a .crash log from an OS X application today -- apparently Xcode hasn't supported symbolication for OS X applications for a while, even if you have a .dSYM -- and your answer allowed me to finally get a line number for a crash. Thanks! – Introrse

there is a little mistake atos -o MyApp.app/MyApp -arch armv7 -l 0x29000 0x0044e89a – Downhearted

Just a note that if your app doesn't include debug symbols you can replace the -o part with the symbols in you .dSYM file (MyApp.app.dSYM/Contents/Resources/DWARF/MyApp) – Amy

the number after + is a decimal number, and it is the result of stack address - load address. So you will find that the first hex number is the sum of the latter two numbers. – Juror

This was so incredibly helpful for debugging a tiny blurry screenshot of a crashlog. – Adipose

Answer 3

Simply use dwarfdump:

dwarfdump --arch armv7 myApp.dSYM --lookup 0xaabbccdd | grep 'Line table'

No need to do any calculations at all.

(From Get symbol by address (symbolicating binary, iOS build)).

Ignaciaignacio

Does that still work on crash logs from iOS 6–7? That's what I used to do with Mac crash logs, but it stopped working around the time of Lion. – Sava

Yes, I just used it on two iOS 6.1.3 crash reports, on Mountain Lion. – Ignaciaignacio

FWIW, dwarfdump failed for me for an armv7s arch, whereas doing the math with atos worked. – Livery

Just tried using dwarfdump then doing the math as outlined by @Kerni. Math worked dwarfdump didn't but as with Scott this was for an armv7s architecture. – Semi

Answer 4

For whom that certain times doesn't have the value for Load Address like this:

Jan 14 11:02:39 Dennins-iPhone AppName[584] <Critical>: Stack Trace: (
    0   CoreFoundation                      0x2c3084b7 <redacted> + 150
    1   libobjc.A.dylib                     0x39abec8b objc_exception_throw + 38
    2   CoreFoundation                      0x2c21cc35 CFRunLoopRemoveTimer + 0
    3   AppName                             0x0005a7db AppName + 272347  

I've created a simple bash to help me debug:

#! /bin/bash
read -p "[Path] [App Name] [Stack Address] [DecimalSum] " path appName stackAddress decimalSum
loadAddress=`echo "obase=16;ibase=10;$((stackAddress-decimalSum))" | bc`
atos -o $path/Payload/$appName.app/$appName -l $loadAddress $stackAddress -arch armv7

It just reads the path for the app, the app name, the stack address, and the value after "+" signal (the decimal value) and then find the value for load address to run atos command.

Diplex

This solution worked perfectly for an exception a beta tester sent me (from Console.app) that did not generate a crash report. Thank you! – Punjabi