象征堆栈跟踪而不会崩溃

本文介绍了象征堆栈跟踪而不会崩溃的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

有什么方法可以表示不是完整崩溃报告的堆栈跟踪?

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

我正在将[NSThread callStackSymbols]的字符串结果记录到我们的服务器中.这不会提供完整格式的崩溃报告，而只会给出未符号化的堆栈跟踪(下面的示例).

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).

我试图象征着这一点.我还尝试过替换来自同一版本的实际崩溃报告的线程0堆栈跟踪.两者都不起作用.我在应用档案中确实有构建的dSYM.有什么方法可以在发行版本中不留任何符号?

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).

如果您具有堆栈跟踪来自的应用程序版本的dSYM，那么您实际上可以将其变成有用的东西.在此处阅读此答案会导致这篇文章对我有很大帮助.我在堆栈跟踪的顶部有这行:

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

这里有两个选项，都涉及一些数学运算.如果您选择atos，则只需进行一次数学运算即可，一次调用即可查找所有步骤.

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.

要使用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:

通过从堆栈地址值中减去符号偏移值来计算加载地址值(load address = -symbol offset)，当然，您必须将它们转换为相同的基数

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

在我的情况下是0x1000D4000

使用装载地址和堆栈地址通过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进行所有操作的好处是，您只需列出堆栈跟踪中的所有地址，即可立即获得可读的格式.

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.

要使用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).

对于我来说，这是64位的0x100000000.

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

将符号偏移量值(堆栈跟踪中 MyApp + ... 之后的数字，在我的情况下为236136)转换为十六进制并将结果添加到幻灯片值.您现在得到的号码称为文件地址(file address = symbol offset + slide)

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)

在我的情况下，结果为0x100039A68.

In my case this resulted in 0x100039A68.

使用dwarfdump --lookup <file address> --arch <architecture> <path to dSYM>

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