LLDB 无法检查变量（在 Xcode 中）
LLDB fails to examine variables (in Xcode)
特别是 print 命令通常（80-90% 的失败率）不起作用
我已经验证过：
https://developer.apple.com/library/content/qa/qa1947/_index.html
示例 1
(lldb) p prevMsg
错误：无法实现：无法获取 runOnce 的值：从值中提取数据失败错误：在 DoExecute 中出错，无法 PrepareToExecuteJITExpression
示例 2 一个更典型的示例，让您进入计算的石器时代：
(lldb) p activeNetworkRequests
错误：执行被中断，原因：EXC_BAD_ACCESS（代码=1，地址=0x1700530）。进程已经返回到表达式求值前的状态。
自 Xcode 7 以来，情况似乎越来越糟。
打印闭包封闭函数范围内的变量尤其无望。
代码库不小，大约15K行。在这里隔离和重现所有代码是不切实际的。
肯定还有其他人遇到过这种情况吗？
更新：有人告诉我表达式的优点 --unwind-on-error=0 -- 有问题的变量，大概是 example2
更新 2：
代码：
Util.log("Returning \(key) from file cache", [.Caches])
输出：
08:03:11.201 v2.0.64d other TwoStageCache.swift objectForKey(_:completion:)[95]: Returning https://example.server.com/Storage/Retrieve?FileName=accounts/person@domain.com/resource/47a58660-26d1-11e7-8e7f-c9f4cd679b03.html from file cache
（所以key的值没问题）
(lldb) fr var key
(URL) key = unable to read data
(lldb) print key
error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0x1d787583).
The process has been returned to the state before expression evaluation.
如果我们查看崩溃：
(lldb) expression --unwind-on-error=0 -- key
libobjc.A.dylib`objc_retain:
0x22562b0 <+0>: pushl %ebp
0x22562b1 <+1>: movl %esp, %ebp
0x22562b3 <+3>: subl [=14=]x8, %esp
0x22562b6 <+6>: calll 0x22562bb ; <+11>
0x22562bb <+11>: popl %ecx
0x22562bc <+12>: movl 0x8(%ebp), %eax
0x22562bf <+15>: testl %eax, %eax
0x22562c1 <+17>: je 0x22562e1 ; <+49>
0x22562c3 <+19>: movl (%eax), %edx
-> 0x22562c5 <+21>: testb [=14=]x2, 0x10(%edx)
发件人：
1 $__lldb_expr(UnsafeMutablePointer<Any>) -> ()
2 Beta Viewer`@objc AppDelegate.init() -> AppDelegate:
3 sharedEnchantment`partial apply for TwoStageCache.(objectForKey(URL, completion : (imgData : Data?, err : BBError?) -> ()) -> ()).(closure #1)
4 sharedEnchantment`thunk:
提前为这篇文章道歉，但希望这些信息值得一读...
lldb 有两种查看变量的方法(*)：print 和frame variable。
print 并不是真正主要用于打印变量——这只是它实际作用的副作用。 print 是 expression 的别名，它让您更了解它是什么：一个完整的表达式求值器，其中 运行 是您在停止时传递的表达式代码。
它构建了一个模拟当前 pc 上的代码的上下文（包括 Class/Protocol 上下文），然后获取您传递给它的代码片段，在该上下文中编译它，JIT 的结果，插入 JIT'将代码编辑到您正在调试的进程中并 运行s 它。这非常强大——您可以更改值、调用程序中的函数、引入新函数、新类型等。但是也有很多机制可以让它运行，并且 swift 其中一些机制是很难做到正确。
frame variable 只能打印当前帧中的局部变量和参数（使用 -g 标志也可以打印全局变量和静态变量）。它不能调用函数，或者 print 可以做的任何其他奇特的事情。它确实理解变量访问语法的有限子集，因此：
(lldb) 帧变量 foo.bar.baz
会起作用。但在幕后，它需要做的就是读取调试信息以找到变量、它的类型以及它在内存中的位置，然后它可以从该信息中提取值。因此，它的工作速度更快，功能更强大 - 这是人们通常要求 print 完成的工作的很大一部分。
请注意，您可以通过使用 -O 标志为使用 frame variable 访问的变量获取 "object printing"，并且它支持与 print 相同的结果格式选项.对于上下文，Xcode "Locals" 视图大致相当于调用 frame variable.
我倾向于使用 frame variable 来进行简单的本地打印，但即使您喜欢使用一个命令来满足您的所有需求 - 这将是 print - 很高兴知道有一个后备方案如果 print 由于某种原因失败。
回到你的例子...
示例 1：print 在 Swift 中所做的其中一件事是将所有可见的局部变量引入表达式的上下文中，以便您的代码可以使用它们。示例 1 中的错误是因为无法实现其中一个局部变量——也许它只是由协议一致性指定的，我们无法弄清楚它到底是什么——所以我们未能构建上下文，这意味着解析或 JIT 步骤失败。 print 代码对此类故障进行了预扫描并忽略了失败的局部变量，但您发现了这种扫描遗漏的情况。
frame variable 可能也无法打印 runOnce 但由于它不依赖于当前上下文，因此无法做到这一点不会影响您打印其他变量的能力.
如果你能重现这个问题，即使你不能让我们使用该项目，我们通常也可以从 lldb 的调试日志中找出发生了什么。因此，将调试会话驱动到打印将要失败的点，然后执行：
(lldb) log enable -f /tmp/lldb-log.txt lldb expr types
然后 运行 失败的表达式。然后获取该日志，并按照此处所述提交错误：
https://swift.org/contributing/#reporting-bugs
示例 2：activeNetworkRequests 是 属性 吗？这些要求我们调用 "get" 方法来访问它们，我已经看到一些 lldb 没有发出代码来正确调用 属性 getter 的情况。上面的日志将向我们展示发出的代码，我们或许可以从那里判断出哪里出了问题。当然，如果你能制作一个测试用例，你可以发送总是最好的错误，但这通常是不可能的...
(*)对于 gdb 用户，这非常接近 info locals vrs。 print...
特别是 print 命令通常（80-90% 的失败率）不起作用
我已经验证过： https://developer.apple.com/library/content/qa/qa1947/_index.html
示例 1
(lldb) p prevMsg
错误：无法实现：无法获取 runOnce 的值：从值中提取数据失败错误：在 DoExecute 中出错，无法 PrepareToExecuteJITExpression
示例 2 一个更典型的示例，让您进入计算的石器时代：
(lldb) p activeNetworkRequests
错误：执行被中断，原因：EXC_BAD_ACCESS（代码=1，地址=0x1700530）。进程已经返回到表达式求值前的状态。
自 Xcode 7 以来，情况似乎越来越糟。
打印闭包封闭函数范围内的变量尤其无望。
代码库不小，大约15K行。在这里隔离和重现所有代码是不切实际的。
肯定还有其他人遇到过这种情况吗？
更新：有人告诉我表达式的优点 --unwind-on-error=0 -- 有问题的变量，大概是 example2
更新 2：
代码：
Util.log("Returning \(key) from file cache", [.Caches])
输出：
08:03:11.201 v2.0.64d other TwoStageCache.swift objectForKey(_:completion:)[95]: Returning https://example.server.com/Storage/Retrieve?FileName=accounts/person@domain.com/resource/47a58660-26d1-11e7-8e7f-c9f4cd679b03.html from file cache
（所以key的值没问题）
(lldb) fr var key
(URL) key = unable to read data
(lldb) print key
error: Execution was interrupted, reason: EXC_BAD_ACCESS (code=1, address=0x1d787583).
The process has been returned to the state before expression evaluation.
如果我们查看崩溃：
(lldb) expression --unwind-on-error=0 -- key
libobjc.A.dylib`objc_retain:
0x22562b0 <+0>: pushl %ebp
0x22562b1 <+1>: movl %esp, %ebp
0x22562b3 <+3>: subl [=14=]x8, %esp
0x22562b6 <+6>: calll 0x22562bb ; <+11>
0x22562bb <+11>: popl %ecx
0x22562bc <+12>: movl 0x8(%ebp), %eax
0x22562bf <+15>: testl %eax, %eax
0x22562c1 <+17>: je 0x22562e1 ; <+49>
0x22562c3 <+19>: movl (%eax), %edx
-> 0x22562c5 <+21>: testb [=14=]x2, 0x10(%edx)
发件人：
1 $__lldb_expr(UnsafeMutablePointer<Any>) -> ()
2 Beta Viewer`@objc AppDelegate.init() -> AppDelegate:
3 sharedEnchantment`partial apply for TwoStageCache.(objectForKey(URL, completion : (imgData : Data?, err : BBError?) -> ()) -> ()).(closure #1)
4 sharedEnchantment`thunk:
提前为这篇文章道歉，但希望这些信息值得一读...
lldb 有两种查看变量的方法(*)：print 和frame variable。
print 并不是真正主要用于打印变量——这只是它实际作用的副作用。 print 是 expression 的别名，它让您更了解它是什么：一个完整的表达式求值器，其中 运行 是您在停止时传递的表达式代码。
它构建了一个模拟当前 pc 上的代码的上下文（包括 Class/Protocol 上下文），然后获取您传递给它的代码片段，在该上下文中编译它，JIT 的结果，插入 JIT'将代码编辑到您正在调试的进程中并 运行s 它。这非常强大——您可以更改值、调用程序中的函数、引入新函数、新类型等。但是也有很多机制可以让它运行，并且 swift 其中一些机制是很难做到正确。
frame variable 只能打印当前帧中的局部变量和参数（使用 -g 标志也可以打印全局变量和静态变量）。它不能调用函数，或者 print 可以做的任何其他奇特的事情。它确实理解变量访问语法的有限子集，因此：
(lldb) 帧变量 foo.bar.baz
会起作用。但在幕后，它需要做的就是读取调试信息以找到变量、它的类型以及它在内存中的位置，然后它可以从该信息中提取值。因此，它的工作速度更快，功能更强大 - 这是人们通常要求 print 完成的工作的很大一部分。
请注意，您可以通过使用 -O 标志为使用 frame variable 访问的变量获取 "object printing"，并且它支持与 print 相同的结果格式选项.对于上下文，Xcode "Locals" 视图大致相当于调用 frame variable.
我倾向于使用 frame variable 来进行简单的本地打印，但即使您喜欢使用一个命令来满足您的所有需求 - 这将是 print - 很高兴知道有一个后备方案如果 print 由于某种原因失败。
回到你的例子...
示例 1：print 在 Swift 中所做的其中一件事是将所有可见的局部变量引入表达式的上下文中，以便您的代码可以使用它们。示例 1 中的错误是因为无法实现其中一个局部变量——也许它只是由协议一致性指定的，我们无法弄清楚它到底是什么——所以我们未能构建上下文，这意味着解析或 JIT 步骤失败。 print 代码对此类故障进行了预扫描并忽略了失败的局部变量，但您发现了这种扫描遗漏的情况。
frame variable 可能也无法打印 runOnce 但由于它不依赖于当前上下文，因此无法做到这一点不会影响您打印其他变量的能力.
如果你能重现这个问题，即使你不能让我们使用该项目，我们通常也可以从 lldb 的调试日志中找出发生了什么。因此，将调试会话驱动到打印将要失败的点，然后执行：
(lldb) log enable -f /tmp/lldb-log.txt lldb expr types
然后 运行 失败的表达式。然后获取该日志，并按照此处所述提交错误：
https://swift.org/contributing/#reporting-bugs
示例 2：activeNetworkRequests 是 属性 吗？这些要求我们调用 "get" 方法来访问它们，我已经看到一些 lldb 没有发出代码来正确调用 属性 getter 的情况。上面的日志将向我们展示发出的代码，我们或许可以从那里判断出哪里出了问题。当然，如果你能制作一个测试用例，你可以发送总是最好的错误，但这通常是不可能的...
(*)对于 gdb 用户，这非常接近 info locals vrs。 print...