Symbolicating Stack Trace without Crash

Question

Is there any way to symbolicate a stack trace that is not a full crash report?

I am logging the string result of [NSThread callStackSymbols] to our server. This doesn\'t

Answer 1

I know this is a rather old question, but I had the same issue now and it took quite some time to find the answer, so I thought I should rather document it (somewhere).

If you have the dSYM for the app version where the stack trace comes from then you can actually turn that into something useful. Reading this answer here lead to this article which helped me a lot. I had this line on top of my stack trace:

0    MyApp                           0x000000010010da68 MyApp + 236136
                                     ^ stack address            ^ symbol offset

You have two options from here, both involves some math. If you go with atos you just have to do the math once though and you can look up all steps with one call.

Using atos

To use atos you need the stack address from the stack trace and you need to find out the load address through some math:

1. Calculate the load address value by subtracting the symbol offset value from the stack address value (load address = stack address - symbol offset) of course you have to convert them to the same base to do that

   In my case this was 0x1000D4000

2. Look up your stack trace entries with atos using the load address and the stack addresses from the stack trace with atos -arch <architecture> -o <path to executable inside (!) the dSYM> -l <load address> <stack address 1> <stack address 2> ...

   In my case this was atos -arch arm64 -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp -l 0x1000D4000 0x000000010010da68

Please keep in mind that you have to supply the path to the actual executable inside the dSYM, otherwise you'll only get an error message. The nice thing about doing all this with atos is that you can just list all the addresses from your stack trace and you'll get a readable format at once.

Using dwarfdump

To use dwarfdump you need the file address corresponding to the stack address in the stack trace.

1. Find out the slide value for the architecture where the stack trace comes from (see Getting the Slide Value in the linked article).

   In my case this was 0x100000000 for 64-bit.

2. Convert the symbol offset value (the number right after MyApp + ... in the stack trace, 236136 in my case) to hex and add the result to the slide value. The number you get now is called the file address (file address = symbol offset + slide)

   In my case this resulted in 0x100039A68.

3. Look up your stack trace entries with dwarfdump using the file address with dwarfdump --lookup <file address> --arch <architecture> <path to dSYM>

   In my case this was dwarfdump --lookup 0x100039A68 --arch arm64 MyApp.dSYM

Answer 2

I ran into the same issue and this answer worked for me: https://stackoverflow.com/a/4954949/299262

You can use atos to symbolicate individual addresses as long as you have the dSYM.

example command:

atos -arch armv7 -o 'app name.app'/'app name' 0x000000000

Answer 3

I don't think this is possible. [NSThread callStackSymbols] return the memory address of the functions. It can't be symbolicated without dump the memory right after crashing. When crashing, the addresses are different for each device. Even on one device, if you reboot the phone, addresses changed after another crash. Several guys mentioned atos but it's for crash log, not for callStackSymbols.