ios - 如何在 LLDB for iOS 中找到堆栈跟踪的地址

Question

当我收到崩溃报告时，我的代码中有问题的部分有时看起来像这样，而不是向我显示实际的行号，即使崩溃报告是符号化的:

-[ViewController myMethod:] + 47  

为了对此进行调试，我需要知道这代表我的代码的哪一行，以便我可以直观地检查它、设置断点等。

如上所示，使用 LLDB 获取方法地址加上偏移量的好方法是什么？

注意:此问题不是 how to read a crash report 的重复问题.我知道如何阅读崩溃报告。我非常具体地询问如何使用 LLDB 获取相应的行。其他答案中没有任何内容说明如何做到这一点。它们非常冗长，涉及处理崩溃报告和一般调试的各种事情，但没有显示 LLDB 的具体步骤是什么。请不要复制此错误。

Answer 1

[请注意，只有在您发布的所有构建的 XCode 中保存存档时，这才有效]

您首先需要收集的信息:

• APPNAME:在 Archive 目录中看到的应用的简称(通常是 XCode Target 名称；当您在下面的 Finder 中查看 Archive 目录时，您会立即看到它)。<
• CRASHING_FUNCTION_NAME:无用的 Apple 回溯中显示的函数名称(在 OP 的示例中，-[ViewController myMethod:])
• ARCH:崩溃设备的架构。正确的值很可能是 armv7 或 arm64。如果您不知道，请尝试两者。

好的，这里是步骤:

1. 在 XCode 中转到 Window...Organizer...Archives
2. 右键单击崩溃用户发布的存档，然后选择“在 Finder 中显示”
3. 打开终端 shell 并 cd 到 Finder 中显示的目录

4. 在 shell 中执行以下命令:

   lldb -arch ARCH Products/Applications/APPNAME.app/APPNAME
   

5. 在 lldb 中执行以下操作:

   (lldb) add-dsym dSYMs/APPNAME.app.dSYM/Contents/Resources/DWARF/APPNAME
   
   (lldb) disassemble --name CRASHING_FUNCTION_NAME
   

6. 您现在看到了带有符号的丰富反汇编，您瞧，每一行都显示与原始无用 Apple 回溯相同的十进制偏移量(在 OP 示例中，无用偏移量为 47)，如:

   APPNAME[0xf4a7c] <+47>:  ldr    r0, [r0, r1]
   

7. 如果反汇编有足够的符号来帮助您确定您所在的位置，您也许可以仅根据此信息找出相应的源代码行。

8. 如果没有，还有一个绝招。传递崩溃行的地址:

   (lldb) image lookup -v --address 0xf4a7c
   

9. 现在 lldb 向您展示了丰富的信息集合 --- 比 Apple 堆栈回溯显示的信息丰富，即使它们确实包含行号，并且比 lldb source list 丰富得多——关于在该地址对汇编程序指令做出贡献的所有源代码行。请密切注意 Summary 和 LineEntry 部分。示例:

   Address: APPNAME[0x000f4a7c] (APPNAME.__TEXT.__text + 963740)
   Summary: APPNAME`myclass::myfunc(bool, bool) + 904 [inlined] std::__1::deque<mystruct, std::__1::allocator<mystruct> >::operator[](unsigned long) + 22 at myfile.cpp:37945
            APPNAME`myclass::myfunc(bool, bool) + 882 [inlined] myinlinefunc(int) + 14 at myfile.cpp:65498
            APPNAME`myclass::myfunc(bool, bool) + 868 at myfile.cpp:65498
   Module: file = "/Users/myuser/mydir/arch/Products/Applications/APPNAME.app/APPNAME", arch = "armv7"
   CompileUnit: id = {0x000483a4}, file = "/Users/myuser/mydir/myfile.cpp", language = "objective-c++"
   Function: id = {0x0045edde}, name = "myfunc", range = [0x000f46f4-0x000f572a)
   FuncType: id = {0x0045edde}, decl = myfile.cpp:65291, compiler_type = "void (_Bool, _Bool)"
   Blocks: id = {0x0045edde}, range = [0x000f46f4-0x000f572a)
           id = {0x0045f7d8}, ranges = [0x000f4936-0x000f51c0)[0x000f544c-0x000f5566)[0x000f5570-0x000f5698)
           id = {0x0046044c}, ranges = [0x000f49c6-0x000f49ce)[0x000f49d6-0x000f49d8)[0x000f4a2e-0x000f4a38)[0x000f4a58-0x000f4a82), name = "myinlinefunc", decl = myfile.cpp:37938, mangled = _Z11myinlinefunci, demangled = myinlinefunc(int)
           id = {0x00460460}, ranges = [0x000f4a58-0x000f4a64)[0x000f4a66-0x000f4a82), name = "operator[]", decl = deque:1675, mangled = _ZNSt3__15dequeI12mystructNS_9allocatorIS1_EEEixEm, demangled = std::__1::deque<mystruct, std::__1::allocator<mystruct> >::operator[](unsigned long)
   LineEntry: [0x000f4a7c-0x000f4a82): /Applications/Xcode7.3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/deque:1678:14
   Symbol: id = {0x00000805}, range = [0x000f46f4-0x000f572a), name="myclass::myfunc(bool, bool)", mangled="_ZN7myclass7myfuncEbb"
   Variable: id = {0x00460459}, name = "myvar1", type = "int", location =     , decl = myfile.cpp:37938
   Variable: id = {0x0045f7dd}, name = "myvar2", type = "bool", location =  , decl = myfile.cpp:65583
   Variable: id = {0x0045edf2}, name = "this", type = "myclass *", location =  [sp+56], decl =
   Variable: id = {0x0045ee01}, name = "myvar3", type = "bool", location = , decl = myfile.cpp:65291
   Variable: id = {0x0045ee0e}, name = "myvar4", type = "bool", location = , decl = myfile.cpp:65292
   

10. 在Summary下的这个例子中，我们可以看到崩溃的行实际上是来自myclass::myfunc()的代码组合，myinlinefunc() 和 std::deque::operator[]。这种混搭对于优化代码来说非常常见。这通常足以找到代码中有问题的源代码行。在 LineEntry 下，我们看到构成该汇编程序行的嵌套最多的代码的行号，在本例中是在 STL std::deque 代码中，但在其他代码中cases 可能是您在代码中想要的确切行号。

11. 现在唯一剩下的问题是:为什么 到底 Apple 不在原始回溯中为我们做这件事？他们显然拥有所有这些信息!他们为什么要让我们跳过这样的圈套？他们在隐藏什么？