[SR-6156] LLDB: warning: initialization of variable '$__lldb_error_result' #4384

keith · 2017-10-16T08:16:37Z


Previous ID	SR-6156
Radar	rdar://problem/35002947
Original Reporter	@keith
Type	Bug
Status	Closed
Resolution	Done

Additional Detail from JIRA


Votes	41
Component/s	LLDB for Swift
Labels	Bug
Assignee	@slavapestov
Priority	Medium

md5: 48509e726972078e013416019229b090

Issue Description:

This test case:

import Foundation

final class Foo {
    func bar() {
        DispatchQueue.main.async { [weak self] in
            if let `self` = self {
                print(self)
            }
        }
    }
}

let foo = Foo()
foo.bar()
dispatchMain()

Causes this error when attempting to `po self` inside of the dispatch closure:

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
    ~~~~^~~~~~~~~~~~~~~~~~~~
    _

error: <EXPR>:18:5: error: value of type 'Foo' has no member '$__lldb_wrapped_expr_0'
    $__lldb_injected_self.$__lldb_wrapped_expr_0(
    ^~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~

To reproduce this you can compile and debug it with this:

$ swiftc -g foo.swift
$ lldb ./foo
(lldb) target create "./foo"
Current executable set to './foo' (x86_64).
(lldb) br set -f foo.swift -l 7
Breakpoint 1: where = foo`closure #&#8203;1 () -> () in foo.Foo.bar() -> () + 118 at foo.swift:7, address = 0x0000000100001ec6
(lldb) r
...
Target 0: (foo) stopped.
(lldb) po self
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
    ~~~~^~~~~~~~~~~~~~~~~~~~
    _

error: <EXPR>:18:5: error: value of type 'Foo' has no member '$__lldb_wrapped_expr_0'
    $__lldb_injected_self.$__lldb_wrapped_expr_0(
    ^~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~

This is probably the same core issue as https://bugs.swift.org/browse/SR-3886 but I wanted to file it separately since it has a different test case.

The text was updated successfully, but these errors were encountered:

slavapestov · 2017-10-16T09:06:39Z

@swift-ci create

NachoSoto · 2017-10-16T18:30:21Z

FWIW I think I've been seeing this since Swift 1.0.

slavapestov · 2017-10-16T21:58:51Z

So it's not a regression? Sorry, management won't let us fix it 😉

keith · 2017-12-22T19:33:06Z

I've made some progress on this. So the problem for this specific case is that when lldb attempts to find `self` here, it finds the optional one, and ends up adding the extension to Optional, yet the `self` that ends up getting accessed is the non optional one, so the extension doesn't apply. This is the cause of the second half of this error.

This isn't super surprising since in this case you can even see the problem by running `fr v`:

(@lvalue second.Foo?) self = 0x0000000101303740
(second.Foo) self = 0x0000000101303740 {}

Since you end up with multiple self vars here. I'm not exactly sure what the solution is yet, or if it's even on the lldb side, but I'm still looking into it.

keith · 2017-12-23T03:40:36Z

Upon more investigation, the problem isn't the multiple `self` variables, it's that where lldb is fetching the variables from, SymbolContext->GetFunctionBlock->GetBlockVariableList, only includes the optional self, and not the non-optional one. You can see this using the python API to access the same variables:

# From some lldb python function
frame = context.GetFrame()
block = frame.GetFunction().GetBlock()
# All the Trues means don't filter out any specific types of variables
variables = block.GetVariables(frame, True, True, True, lldb.eDynamicDontRunTarget)
for variable in variables:
    print variable

In this case you end up with just the optional `self`. If you instead access the variables directly from the frame, you get both.

keith · 2018-03-28T23:38:12Z

Since apple/swift#15306 you can now do this without the backticks, but lldb still has this issue (unsurprisingly)

omochi · 2018-10-03T08:23:20Z

I recorded video about same issue.
https://twitter.com/omochimetaru/status/1047384921180758016

swift-ci · 2019-02-05T02:18:10Z

Comment by Erica Ehrhardt (JIRA)

We keep running into this one at Thumbtack. One way it manifests in Xcode is that tracepoints showing the value of locals in a closure that uses self like this don't print anything. Another is that the ℹ button results in the same initialization of variable '$__lldb_error_result' was never used message as in the issue description. The workaround in is to change the name of the unwrapped self to something else (if possible), but it looks a little goofy.

swift-ci · 2019-02-05T19:15:04Z

Comment by Daniel W Roth (JIRA)

Agreed. This effectively nullifies the value of being able to write (the very common)

guard let self = self else { return }

swift-ci · 2019-03-05T01:54:56Z

Comment by Christopher Fuller (JIRA)

I completely and wholeheartedly agree with dwroth@gmail.com (JIRA User) !! As Swift developers, we LOVE the fact that SE-0079 was accepted and released with Swift 4.2. We have adopted that syntax ever since, however we regularly encounter this debugging issue. This causes a lot of friction in our engineering process and results in Swift engineers resorting to using `strongSelf` or `this` or `_self` or whatever. These workarounds are not ideal at all - we can do better![]( Please, please give this bug some attention)![]( Swift developers will very much appreciate this)!!

swift-ci · 2019-03-05T02:22:33Z

Comment by Borys Gurtovyi (JIRA)

Please, give this bug some attention! Thank you 👍

swift-ci · 2019-03-05T02:27:25Z

Comment by Johnson Hsieh (JIRA)

This would be great

swift-ci · 2019-03-05T03:13:52Z

Comment by Nicholas (JIRA)

This one impacts us daily. Would be great to see a resolution.

swift-ci · 2019-03-05T05:47:44Z

Comment by Owen Thomas (JIRA)

I've been running into this for a while now too but didn't know there was a bug report for it till just now. Would love to see a fix for this one!

swift-ci · 2019-03-05T18:08:04Z

Comment by Michael Doshi (JIRA)

I've been running into this over the past couple years. Would be great to have a fix 👍

swift-ci · 2019-03-05T18:20:28Z

Comment by Connor Wybranowski (JIRA)

Would love to see a fix for this! 👍

slavapestov · 2019-03-05T19:19:03Z

I'm looking at this now, but at least some of you will be disappointed... 🙂 I suspect there are multiple root cause failures that all manifest as an error "value of type 'Foo' has no member '$__lldb_wrapped_expr_0'", one of them being this issue with a shadowed 'self' declaration. However, once I fix this issue, we can see what else remains.

swift-ci · 2019-04-25T21:20:46Z

Comment by Manjunath Chandrashekar (JIRA)

Have crossed path with this issue when working on Generics recently. https://github.com/manjuhere/GenericsBugDemo Would be glad if it can help in solving the issue.

swift-ci · 2019-05-14T01:00:52Z

Comment by rounak jain (JIRA)

Would be really great to have a fix for this, given a lot of times issues can't be reproduced, and having a broken debugger at that instant is very limiting.

swift-ci · 2019-05-14T19:17:39Z

Comment by Elliott Williams (JIRA)

I've been using this workaround in lldb to sidestep the issue.

Run fr v -D 1 to and get a pointer to self
Move up stack frames to get past the frame containing the problematic self reassignment. (in practice, it's easy to move up to `main`)
Run e -Ol swift – unsafeBitCast(<pointer>, to: <type of self>), and you'll have a reference to the object you can manipulate like you would with po

swift-ci · 2019-10-04T23:45:17Z

Comment by Leonid Kokhnovych (JIRA)

This one impacts us daily. It would be great to see a resolution.

keith · 2020-10-14T21:03:12Z

The original specific example here has been fixed for a while. If anyone else has a new repro case please file a new ticket!

swift-ci transferred this issue from apple/swift-issues Apr 25, 2022

shahmishal transferred this issue from apple/swift May 5, 2022

This issue was closed.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[SR-6156] LLDB: warning: initialization of variable '$__lldb_error_result' #4384

[SR-6156] LLDB: warning: initialization of variable '$__lldb_error_result' #4384

keith commented Oct 16, 2017

slavapestov commented Oct 16, 2017

NachoSoto commented Oct 16, 2017

slavapestov commented Oct 16, 2017

keith commented Dec 22, 2017

keith commented Dec 23, 2017

keith commented Mar 28, 2018

omochi commented Oct 3, 2018

swift-ci commented Feb 5, 2019

swift-ci commented Feb 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

slavapestov commented Mar 5, 2019

swift-ci commented Apr 25, 2019

swift-ci commented May 14, 2019

swift-ci commented May 14, 2019

swift-ci commented Oct 4, 2019

keith commented Oct 14, 2020

[SR-6156] LLDB: warning: initialization of variable '$__lldb_error_result' #4384

[SR-6156] LLDB: warning: initialization of variable '$__lldb_error_result' #4384

Comments

keith commented Oct 16, 2017

slavapestov commented Oct 16, 2017

NachoSoto commented Oct 16, 2017

slavapestov commented Oct 16, 2017

keith commented Dec 22, 2017

keith commented Dec 23, 2017

keith commented Mar 28, 2018

omochi commented Oct 3, 2018

swift-ci commented Feb 5, 2019

swift-ci commented Feb 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

swift-ci commented Mar 5, 2019

slavapestov commented Mar 5, 2019

swift-ci commented Apr 25, 2019

swift-ci commented May 14, 2019

swift-ci commented May 14, 2019

swift-ci commented Oct 4, 2019

keith commented Oct 14, 2020