17

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

-[ViewController myMethod:] + 47  

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

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

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

4

3 回答 3

11

这是我发现有效的方法:

首先你需要找到方法本身的地址。

image lookup -v -F "-[ViewController myMethod:]"

结果你会看到很多信息,但是范围部分会给你想要的

... range = [0x000708c0-0x00070c6c) ...

(其中 0x000708c0 是方法的地址)

现在要添加给定的偏移量 47,只需使用 LLDB 为您计算:

(lldb) p/x 0x000708c0 + 47
(int) $0 = 0x000708ef

你得到你的答案,违规行在 0x000708ef

或者更好的是,根据 Jason Molenda 的回答,直接进入代码清单,它将显示行号:

(lldb) source list -a `0x000708c0 + 47`

编辑:根据 Jason Molenda 的回答进行了改进

于 2013-08-08T20:28:34.000 回答
11

[请注意,这仅适用于您在 XCode 中保存您发布的所有构建的档案]

您需要首先收集的信息:

  • APPNAME:在存档目录中看到的应用程序的短名称(通常是 XCode 目标名称;当您在下面的 Finder 中查看存档目录时,您会立即看到它)。
  • CRASHING_FUNCTION_NAME:在无用的 Apple 回溯中显示的函数名称(在 OP 的示例中,-[ViewController myMethod:]
  • ARCH:崩溃的设备架构。最有可能的正确值是armv7arm64。如果您不知道,请尝试两者。

好的,步骤如下:

  1. 在 XCode 中转到 Window...Organizer...Archives
  2. 右键单击崩溃用户所拥有的版本的存档,然后选择在 Finder 中显示
  3. 打开终端外壳并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 回溯相同的十进制偏移量(在 OPs 示例中,无用偏移量是47),如下所示:

    APPNAME[0xf4a7c] <+47>:  ldr    r0, [r0, r1]
    
  7. 如果反汇编有足够的符号来帮助您确定您所在的位置,您也许可以仅从这些信息中找出相应的源代码行。

  8. 如果没有,还有另一个很棒的技巧。传递崩溃行的地址:

    (lldb) image lookup -v --address 0xf4a7c
    
  9. 现在lldb向您展示了丰富的信息集合——比 Apple 堆栈回溯显示的内容要丰富得多,即使它们确实包含行号,并且比 lldb 丰富得多source list——关于当时对汇编程序指令有贡献的所有源代码行地址。密切关注SummaryLineEntry部分。例子:

    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下面,我们看到了构成该汇编程序行的最嵌套代码的行号,在这种情况下是在 STLstd::deque代码中,但在其他情况下可能是您在代码中想要的确切行号。

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

于 2017-01-25T18:46:33.460 回答
9

如您所见,您的步骤 ( image lookup+ p/x addr + offset) 将为您提供原始地址。但最初的崩溃报告可能在方法 + 偏移量之前包含一个地址 --- 使用 . 将二进制文件滑动到正确的地址同样容易target modules load。在崩溃报告的末尾应该有一个程序中存在的二进制图像列表,包括加载地址和 UUID。

但更重要的是,虽然地址很好,但您真正追求的是源位置。在这种情况下,一旦您确定了该方法的正确地址(或通过 将其滑动到匹配地址target modules load),您可以使用source list

(lldb) so l -a `addr + offset`

我在这里使用反引号表示法,它进行内联表达式评估。大多数带有地址的命令都有一个方便的快捷方式:如果省略空格,则可以编写不带反引号的表达式:

(lldb) so l -a addr+offset

您也可以使用image lookup地址。如果您有调试信息,这将告诉您此时变量的当前位置。为什么这很有用?因为大多数崩溃报告都包含崩溃时的寄存器上下文,所以当前在寄存器中的任何变量都会提供给您(-v获取所有寄存器位置信息所必需的)。

(lldb) im loo -v -a addr+offset

最后——这是行不通的,因为你正在处理一个 Objective-C 方法名——但是使用一个简单的 C 函数名,只要你将函数名转换为指针类型(向函数指针添加偏移量是不合法的 C)。例如

(lldb) so l -a (char*)main+10
于 2013-08-08T20:54:05.617 回答