我是 lldb 的新手，正在尝试使用 po [$eax class] 来诊断错误
UI 中显示的错误是：
Thread 1: EXC_BREAKPOINT (code=EXC_i386_BPT, subcode=0x0)
这是 lldb 控制台，包括我输入的内容和返回的内容：
(lldb) po [$eax class]
error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0xb06b9940).
The process has been returned to the state before expression evaluation.
全局断点状态切换已关闭。
【问题讨论】：
清理项目并重新启动 Xcode 对我有用。
【讨论】：
我正在添加我的解决方案，因为我一直在努力解决同样的问题，但我在任何地方都没有找到这个解决方案。
在我的情况下，我必须运行 Product -> Clean Build Folder（Clean + Option 键）并重建我的项目。断点和 lldb 命令开始正常工作。
【讨论】：
您的应用程序正在停止，因为您正在运行的代码引发了未捕获的 Mach 异常。 Mach 异常相当于 Mach 内核的 BSD 信号 - 它构成了 macOS 操作系统的最低级别。
在这种情况下，特定的马赫异常是EXC_BREAKPOINT。 EXC_BREAKPOINT 是一个常见的混淆源......因为它的名称中有“断点”一词，人们认为它是一个调试器断点。这并不是完全错误的，但异常的使用比这更普遍。
EXC_BREAKPOINT实际上是Mach低层在执行某条指令（陷阱指令）时报告的异常。 lldb 使用该陷阱指令来实现断点，但它也可以在系统软件的各个位中用作assert 的替代方法。例如，如果您访问数组的末尾，则 swift 会使用此错误。这是一种在发生错误时立即停止程序的方法。如果您在调试器之外运行，这将导致崩溃。但是，如果您在调试器中运行，则控制权将返回给调试器，并带有 EXC_BREAKPOINT 停止原因。
为避免混淆，如果陷阱是 lldb 插入到您正在调试的程序中以实现调试器断点的陷阱，则 lldb 永远不会显示 EXC_BREAKPOINT 作为停止原因。它总是说breakpoint n.n。
因此，如果您看到一个线程以EXC_BREAKPOINT 作为其停止原因而停止，这意味着您遇到了某种致命错误，通常是在您的程序使用的某些系统库中。此时的回溯将向您显示引发该错误的组件。
无论如何，在遇到该错误后，您尝试通过运行po [$eax class] 调用其上的类方法来找出 eax 寄存器中值的类。调用该方法（这将导致代码在您正在调试的程序中运行）会导致崩溃。这就是您引用的“错误”消息告诉您的内容。
这几乎可以肯定是因为$eax 没有指向有效的 ObjC 对象，所以你只是在某个随机值上调用一个方法，这会崩溃。
注意，如果您正在调试一个 64 位程序，那么 $eax 实际上是实际参数传递寄存器 - $rax 的低 32 位。 64 位指针的底部 32 位不太可能是有效的指针值，因此在其上调用 class 导致崩溃也就不足为奇了。
如果您尝试在 64 位 Intel 上对第一个传递的参数（ObjC 方法中的 self）调用 class，您真的很想做：
(lldb) po [$rax class]
注意，这也不太可能奏效，因为$rax 仅在函数开头保留self。然后它被用作临时寄存器。因此，如果您有任何方法进入该函数（您的代码在某些测试中致命失败的事实似乎很可能）$rax 不太可能仍然持有self。
还要注意，如果这是一个 32 位程序，那么 $eax 实际上并没有用于参数传递 - 32 位 Intel 代码在堆栈中传递参数，而不是在寄存器中。
无论如何，要找出问题所在，首先要做的是在收到此异常时打印回溯，并查看发生此错误时正在运行的代码。
【讨论】：
answer 以方便所有人阅读？我想大多数人很难理解你的意思。
thread backtrace（有关详细信息，请参阅help thread backtrace。）。还有一个快速访问别名bt 来回溯当前或一组线程（或all 用于所有线程）。 lldb 还有一个apropos 命令，它将在帮助中搜索关键字：例如apropos backtrace。最后，如果您来自 gdb，lldb.llvm.org/use/map.html 可能会帮助您确定方向。