Question

特别是print命令通常（80-90％失败率）不起作用

我已经验证过了： https://developer.apple.com/library/content/qa/qa1947/_index.html

示例1

（lldb）p prevMsg

错误：无法实现：无法获取runOnce的值：从值失败的数据中提取数据错误：在DoExecute中出错，无法准备执行任务JITExpression

示例2一个更典型的例子，让您进入计算的石器时代：

（lldb）p activeNetworkRequests

错误：执行被中断，原因：EXC_BAD_ACCESS（代码= 1，地址= 0x1700530）。该过程已返回到表达式评估之前的状态。

自Xcode 7以来，这似乎越来越严重。

从闭合函数的封闭函数中限定的打印变量尤其没有用处。

代码库不小，大约15K行。在这里隔离和重现所有代码是不切实际的。

当然其他人正在经历这个？

更新：我告诉了表达式的优点--unwind-on-error = 0 - 变量问题，大概是为了示例2

更新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   $0x8, %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  $0x2, 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:

Answer 1

对于这篇文章提前抱歉，但希望这些信息值得一读......

lldb有两种查看变量的方法（*）：print和frame variable。

print并不是主要用于打印变量 - 这只是它真正起作用的副作用。 print是expression的别名，它让您更加了解它是什么：一个完整的表达式计算器，它运行您在代码中停止的位置传递的表达式。

它构建一个上下文，模拟当前pc上的代码（包括类/协议上下文），然后获取传递它的代码片段，在该上下文中编译它，JIT的结果，将JIT代码插入到您正在调试并运行它的进程。这是非常强大的 - 您可以更改值，调用程序中的函数，引入新函数，新类型等。但是还有很多机器只是为了让它继续下去，并且快速地使用这些机器很难实现

frame variable只能在当前帧中打印本地和参数（-g标志它也可以打印全局和静态）。它不能调用函数，也不能调用任何其他奇特的东西print。它确实理解变量访问语法的有限子集，因此：

（lldb）帧变量foo.bar.baz

会奏效。但是在幕后，它需要做的就是读取调试信息以查找变量，类型以及它在内存中的位置，然后它可以从该信息中提取值。因此，它的功能更快，更强大 - 这是人们通常要求print做的工作的很大一部分。

注意，您可以使用frame variable标记为-O访问的变量进行“对象打印”，并且它支持与print相同的结果格式选项。对于上下文，Xcode“Locals”视图大致相当于调用frame variable。

我倾向于使用frame variable进行简单的本地打印，但即使您希望使用一个命令来满足您的所有需求 - 这将是print - 如果{我知道有一个回退{ {1}}由于某种原因失败了。

回到你的例子......

示例1：Swift中的一个事项print将所有可见的局部变量引入表达式的上下文中，因此它们可供您的代码使用。示例1中的错误是因为其中一个局部变量无法实现 - 可能它只是由协议一致性指定而我们无法弄清楚它到底是什么 - 所以我们无法构建上下文，这意味着解析或JIT步骤失败。 print代码对此类故障进行了预扫描，并省略了失败的本地人，但您发现此扫描未命中的情况。

print可能也无法打印frame variable，但由于它不依赖于当前上下文，因此无法做到这一点不会影响您打印其他变量的能力。< / p>

如果您可以重现此问题，即使您无法向我们提供项目，我们也可以经常弄清楚lldb的调试日志发生了什么。因此，将调试会话驱动到打印失败的位置，并执行：

runOnce

然后运行失败的表达式。然后获取该日志，并提交错误，如下所述：

https://swift.org/contributing/#reporting-bugs

示例2：activeNetworkRequests是否属性？那些要求我们调用“get”方法来访问它们，我已经看到了一些lldb没有发出代码来正确调用属性getter的情况。上面的日志将向我们显示发出的代码，我们可以从那里告诉我出了什么问题。当然，如果你可以制作测试用例，你可以发送最好的bug，但这通常是不可能的......

（*）对于gdb用户，这非常接近(lldb) log enable -f /tmp/lldb-log.txt lldb expr types vrs。 info locals ...

LLDB无法检查Xcode 8/9 / Swift 3/4

1 个答案: