如何使用 lldb 有效地回溯段故障？答案

【问题标题】：How to efficiently backtrace segment fault using lldb?如何使用 lldb 有效地回溯段故障？
【发布时间】：2015-08-07 15:13:33
【问题描述】：

我是 LLDB 的新手（嗯，实际上是大多数命令行工具的新手）。当我非常关注easy and helpful article 来回溯段错误错误时，我发现我在 Mac OS X 10.10 上使用 LLDB 的输出与作者使用 gdb 作为调试器的输出不同。

为了让问题更清楚。在我使用lldb运行上述文章中相同的代码后，遇到段错误错误，并使用lldb的bt命令，我得到了这个消息。

* thread #1: tid = 0x208541, 0x00007fff8869a05a libsystem_platform.dylib`_platform_memmove$VARIANT$Unknown + 186, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00007fff8869a05a libsystem_platform.dylib`_platform_memmove$VARIANT$Unknown + 186
    frame #1: 0x00007fff8fc08866 libsystem_c.dylib`fgets + 243
    frame #2: 0x0000000100000f34 sf`main + 68
    frame #3: 0x00007fff8e6535c9 libdyld.dylib`start + 1

由于我将我的可执行文件命名为“sf”（段故障的缩写），所以我按照文章中的想法使用了f 2命令。

现在事情出了问题，因为我收到了这条消息。

frame #2: 0x0000000100000f34 sf`main + 68
sf`main:
    0x100000f34 <+68>: leaq   0x5f(%rip), %rdi          ; "%s\n"
    0x100000f3b <+75>: movq   -0x18(%rbp), %rsi
    0x100000f3f <+79>: movq   %rax, -0x20(%rbp)
    0x100000f43 <+83>: movb   $0x0, %al

看起来像汇编语言，与上篇文章中gdb给出的C语言相比，确实没有帮助，即：

#3  0x80484b2 in main (argc=1, argv=0xbffffaf4) at segfault.c:10
10        fgets(buf, 1024, stdin)

所以我的问题是我可以使用 LLDB 获得 C 语言回溯吗？

【问题讨论】：

看来您没有使用调试符号构建程序。如果你这样做了，它看起来会是something like this。在 Mac OS X 10.10.3 启用调试符号（-g 开关）上使用 clang 3.6 构建。

标签： c lldb

【解决方案1】：

编译时需要添加-g标志。另外，我建议使用-O0 标志，它告诉您的编译器执行最少的优化。通过更积极的优化，您可以在调试器中获得奇怪的行为。通常，当我尝试跟踪段错误和类似错误时，我发现条件断点和观察点是最有用的命令。您可以通过breakpoint set --file <filename> --line <line number> --condition '<some C expression>' 在行号处设置条件断点。可以使用w s e -- <address> 设置观察点，其中<address> 是要观察的位置。

【讨论】：