Symbolicating堆栈跟踪不崩溃(Symbolicating Stack Trace wit

有没有什么办法来symbolicate堆栈跟踪不是一个完整的崩溃报告吗？

我登录[NSThread callStackSymbols]的字符串结果到我们的服务器。 这不给一个完全格式化的崩溃报告，但只是unsymbolicated堆栈跟踪（如下图所示）。

我曾尝试只是这symbolicate。 我也曾尝试从相同的构建更换实际崩溃报告的线程0堆栈跟踪。 但是都没有成功。 我有在归档应用程序构建的的dSYM。 有没有办法做到这一点，而不在分布构建留下的符号？

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

Answer 1:

我遇到同样的问题，这个答案为我工作： https://stackoverflow.com/a/4954949/299262

您可以使用ATOS只要你有对的dSYM个人symbolicate地址。

示例命令：

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

Answer 2:

我知道这是一个相当古老的问题，但我现在有同样的问题，并花了相当长的一段时间来找到答案，所以我想我应该相当记录它（的地方）。

如果你有一个应用程序版本的dSYM在堆栈跟踪来源于那么实际上你可以把它转换成有用的东西。 阅读在这里这个回答导致这篇文章这对我帮助很大。 我对我的堆栈跟踪的顶部这一行：

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

你从这里两种选择，既涉及到一些数学。 如果你去atos你就必须做数学题，但一旦和你可以看看了一个呼叫的所有步骤。

使用atos

要使用atos ，你需要从堆栈跟踪堆栈地址 ，您需要找出通过一些数学加载地址 ：

1. 从堆栈地址值（减去符号偏移值计算负载的地址值load address = stack address - symbol offset ），当然你必须将它们转换为相同的基础做

   在我的情况，这是0x1000D4000

2. 查一查你的堆栈跟踪条目与atos使用加载地址 栈地址从堆栈跟踪和atos -arch <architecture> -o <path to executable inside (!) the dSYM> -l <load address> <stack address 1> <stack address 2> ...

   在我的情况，这是atos -arch arm64 -o MyApp.app.dSYM/Contents/Resources/DWARF/MyApp -l 0x1000D4000 0x000000010010da68

请记住，你必须的路径提供给里面的dSYM实际的可执行文件，否则你只会得到一个错误信息。 关于做这一切与好处atos是，你可以只是从你的堆栈跟踪列出所有的地址，你会立刻得到一个可读的格式。

使用dwarfdump

要使用dwarfdump你需要对应于堆栈跟踪堆栈地址 文件地址 。

1. 找出其中的堆栈跟踪来自架构幻灯片值（请参阅获得幻灯片价值链接的文章）。

   在我的情况，这是0x100000000 64位。

2. 转换符号偏移值（MyApp的之后的堆栈跟踪数+ ...， 236136在我的情况），以十六进制，并将结果添加到幻灯片值。 你现在得到的数叫做文件地址 （ file address = symbol offset + slide ）

   在我的情况下，这导致0x100039A68 。

3. 查一查你的堆栈跟踪条目与dwarfdump使用该文件的地址与dwarfdump --lookup <file address> --arch <architecture> <path to dSYM>

   在我的情况，这是dwarfdump --lookup 0x100039A68 --arch arm64 MyApp.dSYM

Answer 3:

我不认为这是可能的。 [NSThread callStackSymbols]返回的功能的存储器地址。 它不能没有崩溃之后转储存储器symbolicated。 崩溃的情况下，地址是为每个设备不同。 即使是一台设备上，如果你重新启动手机，地址，另一个崩溃后改变。 几个小伙子提到ATOS但它的崩溃日志，而不是callStackSymbols。

文章来源: Symbolicating Stack Trace without Crash