有没有办法表示不是完整崩溃报告的堆栈跟踪？
我正在将[NSThread callStackSymbols]的字符串结果记录到我们的服务器上。这不会提供完全格式化的崩溃报告，而只是非符号化的堆栈跟踪（下面的示例）。
我试图象征这一点。我也尝试从同一个构建中替换实际崩溃报告的线程0堆栈跟踪。都没有奏效。我确实在app存档中有构建的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
答案 0 :(得分：3)
我遇到了同样的问题，这个答案对我有用：https://stackoverflow.com/a/4954949/299262
只要您拥有dSYM，就可以使用atos来表示个别地址。
示例命令：
atos -arch armv7 -o 'app name.app'/'app name' 0x000000000
答案 1 :(得分：1)
我知道这是一个相当古老的问题，但我现在遇到了同样的问题，花了很长时间才找到答案，所以我想我应该把它记录下来（某处）。
如果您拥有堆栈跟踪来自的应用程序版本的dSYM，那么您实际上可以将其转换为有用的东西。阅读this answer here导致this article对我有很大帮助。我在堆栈跟踪上面有这一行：
0 MyApp 0x000000010010da68 MyApp + 236136
^ stack address ^ symbol offset
你有两个选项，都涉及一些数学。如果你选择atos，你只需要做一次数学运算，你可以通过一个电话查找所有步骤。
atos 要使用atos，您需要堆栈跟踪中的堆栈地址，您需要通过一些数学找出加载地址：
通过从堆栈地址值中减去符号偏移值来计算加载地址值（load address = stack address - symbol offset）当然你必须将它们转换为相同的基础才能做到这一点
就我而言，这是0x1000D4000
使用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，您需要与堆栈跟踪中的堆栈地址对应的文件地址。
找出堆栈跟踪来自的体系结构的幻灯片值（请参阅链接文章中的获取幻灯片值）。
就我而言，对于64位，这是0x100000000。
转换符号偏移值（堆栈跟踪中的 MyApp + ... 之后的数字，在我的情况下为236136）十六进制并将结果添加到幻灯片值。您现在获得的数字称为文件地址（file address = symbol offset + slide）
在我的情况下，这导致0x100039A68。
使用带有dwarfdump
dwarfdump --lookup <file address> --arch <architecture> <path to dSYM>查找堆栈跟踪条目
就我而言，这是dwarfdump --lookup 0x100039A68 --arch arm64 MyApp.dSYM
答案 2 :(得分：0)
我不认为这是可能的。 [NSThread callStackSymbols]返回函数的内存地址。它不能在没有崩溃后立即转储内存的情况下进行符号化。 崩溃时，每个设备的地址都不同。即使在一台设备上，如果重新启动手机，地址也会在另一次崩溃后发生变化。 有几个人提到了atos，但它是崩溃日志，而不是callStackSymbols。