0

I have a particular file in my app that consistently fails to respond to po commands in the console. This file has a single function that when I breakpoint into and run po I see:

error: warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
    ~~~~^~~~~~~~~~~~~~~~~~~~
    _

The particular variable I'm logging out does not seem to matter as it fails on seemingly every thing. What I'm seeing is that this debugging issue happens most consistently on this file.

So is there a reason why this file in particular could be corrupted?

Alex Bollbach
  • 4,370
  • 9
  • 32
  • 80
  • How about `p`, does that work? – matt Oct 07 '19 at 20:52
  • no, that does not work. – Alex Bollbach Oct 07 '19 at 20:53
  • That's not good. :( This might be a duplicate of https://stackoverflow.com/questions/55515329/unable-to-use-po-command-in-console-debug-area - in any case it seems like one unless you provide info that differentiates it. Can you? – matt Oct 07 '19 at 20:58
  • it appears to be the same error description. in my case, the problem is localized to a single closure in a file. – Alex Bollbach Oct 08 '19 at 15:48
  • That's great. Thank you for narrowing it down. I believe I've seen this kind of thing too and was racking my brains to remember the circumstances. Can you reduce this to a reproducible situation? If so, you could submit a bug report and help save the world. :) – matt Oct 08 '19 at 15:55
  • Check related problem https://stackoverflow.com/a/48249030/5329717 and possible workarounds. – Kamil.S Oct 21 '19 at 08:09

1 Answers1

1

When evaluating expressions, lldb has to replicate the context in which the expression is being run. For instance, if you are stopped in a method of a class, you expect to be able to refer to ivars transparently, and method lookup has to be done looking up the class hierarchy.

Sometimes lldb can't figure out the context, and our failed attempt to wrap your expression in the right context produces expressions that don't compile. That's what you are seeing.

For instance, people started doing:

   guard let self = self! {}

in closures that capture self weakly. The presence of two self's threw this context reconstruction for a loop. And there are many other subtleties that lldb has to get right. Swift is a fairly complex language in this regard.

So if you are seeing this in a particular context, you've likely found another manifestation of this problem. Be sure you try the most recent Xcode if you can, since lldb has fixed a goodly number of this sort of bug recently. If it still doesn't work, please do file a bug, either with http://bugs.swift.org or using Apple's feedback system.

BTW, if you just need to examine variables, the command frame var (aliased to v in recent lldb's will often work when print fails, since it doesn't do most of the complex tricks the expression parser has to do. v is also generally much quicker, since it just examines memory rather than building up, compiling, injecting and running an expression in the debugee...

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63