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 give a fully formatted crash report, but just the unsymbolicated stack trace (example below).
I have tried to symbolicate just this. I have also tried replacing the thread 0 stack trace of an actual crash report from the same build. Neither worked. I do have the dSYM of the build in the app archive. Is there any way to do this without leaving symbols in the distribution build?
0 domino free 0x00072891 domino free + 465041
1 domino free 0x000ea205 domino free + 954885
2 domino free 0x000ea033 domino free + 954419
3 domino free 0x0007fe55 domino free + 519765
4 domino free 0x0006f6d5 domino free + 452309
5 domino free 0x0006f7a3 domino free + 452515
6 domino free 0x0006fb9b domino free + 453531
7 Foundation 0x30558c29 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 + 16
8 Foundation 0x304b06d9 -[NSURLConnectionInternalConnection invokeForDelegate:] + 28
9 Foundation 0x304b06a3 -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] + 198
10 Foundation 0x304b05c5 -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] + 60
11 CFNetwork 0x31f297f5 _ZN19URLConnectionClient23_clientDidFinishLoadingEPNS_26ClientConnectionEventQueueE + 192
12 CFNetwork 0x31f1e4a5 _ZN19URLConnectionClient26ClientConnectionEventQueue33processAllEventsAndConsumePayloadEP20XConnectionEventInfoI12XClientEvent18XClientEventParamsEl + 424
13 CFNetwork 0x31f1e599 _ZN19URLConnectionClient26ClientConnectionEventQueue33processAllEventsAndConsumePayloadEP20XConnectionEventInfoI12XClientEvent18XClientEventParamsEl + 668
14 CFNetwork 0x31f1e1a3 _ZN19URLConnectionClient13processEventsEv + 106
15 CFNetwork 0x31f1e0d9 _ZN17MultiplexerSource7performEv + 156
16 CoreFoundation 0x30abead3 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 14
17 CoreFoundation 0x30abe29f __CFRunLoopDoSources0 + 214
18 CoreFoundation 0x30abd045 __CFRunLoopRun + 652
19 CoreFoundation 0x30a404a5 CFRunLoopRunSpecific + 300
20 CoreFoundation 0x30a4036d CFRunLoopRunInMode + 104
21 GraphicsServices 0x30e7f439 GSEventRunModal + 136
22 UIKit 0x3123acd5 UIApplicationMain + 1080
23 domino free 0x0004fd3b domino free + 322875
24 domino free 0x00004004 domino free + 12292
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:
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: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 thatIn my case this was
0x1000D4000
Look up your stack trace entries with
atos
using the load address and the stack addresses from the stack trace withatos -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.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.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
.Look up your stack trace entries with
dwarfdump
using the file address withdwarfdump --lookup <file address> --arch <architecture> <path to dSYM>
In my case this was
dwarfdump --lookup 0x100039A68 --arch arm64 MyApp.dSYM
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
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.