Swift Debugger intermittently fails to print descriptions for local variables

2
votes

I've been silently dealing with this for months now and finally I feel the need to ask here. 'po' in lldb often results in the following output:

(lldb) error: :3:1: error: use of unresolved identifier 'inView' inView ^~~~~~

I'm writing up a custom animation view controller transition. I'm paused in the animateTransition(using transitionContext:) method. inView is a local variable defined at the start of the method. I'm using it on the next line. I want to query its value. It shows up in the 'variables view' part of the debugger (however just the name and no details).

So I see no reason why this shouldn't print out.

Now, before people talk about optimization, this is a fresh single view application running a default scheme. The default optimization settings for the Swift compiler have no optimization for the debug profile. This is indeed how my project is set up.

So what is the problem??

1
swiftdebugginglldb
Does this help stackoverflow.com/questions/24785567/po-in-lldb-with-swift ? – Martin R
not really. i'll keep reading it over. its concerning that these local vars print out non-deterministically which leads me to believe this is unstable behavior and not some valid inherent problem with printing out these variables. – Alex Bollbach
Does it show with frame variable or frame variable inView? p evaluates an arbitrary expression, which is orders of magnitude more complicated than looking up a variable. – zneak
frame variable was appearing to work. po works sometimes but often not. it tends to work towards the beginning of the method (7 lines in) but not towards the middle (10-15 lines in). its totally unpredictable. – Alex Bollbach
This is a long shot, and I really don't expect it to work, but you could try using ObjC when Swift doesn't work: ex -l objc -O -- inView The -l flag lets you specify the language of the expression to evaluate: you can write an ObjC expression even if you're stopped in a Swift context. – jscs

1 Answers

3
votes

Even at the lowest optimization level (-Onone) the swift compiler does a lot more optimization work than clang does for the C languages at -O0. Swift relies on the optimizer to make its more complex basic model perform well, and needs to do some of this work even at -Onone.

One of the common symptoms of debug info losing to optimization passes is a failure to track the location of variables. The debug information records the variable, but for some address ranges can't reconstruct its location. From your description it sounds like you are hitting this problem.

There's no one cause for this symptom, since the failure is the result of the interaction of all stages of the compiler & optimizer. The more instances of this the swift engineers can see, the more of the bad pathways they can fix. So please file bugs when you see this. The instructions for that are here:

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