Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
keith opened this issue Oct 16, 2017 · 22 comments
Closed

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

keith opened this issue Oct 16, 2017 · 22 comments
Assignees
Labels
bug LLDB for Swift

Comments

@keith
Copy link

@keith keith commented Oct 16, 2017

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.

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Oct 16, 2017

@swift-ci create

@NachoSoto
Copy link

@NachoSoto NachoSoto commented Oct 16, 2017

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

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Oct 16, 2017

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

@keith
Copy link
Author

@keith keith commented Dec 22, 2017

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
Copy link
Author

@keith keith commented Dec 23, 2017

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
Copy link
Author

@keith keith commented Mar 28, 2018

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

@omochi
Copy link

@omochi omochi commented Oct 3, 2018

@swift-ci
Copy link

@swift-ci swift-ci commented Feb 5, 2019

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
Copy link

@swift-ci swift-ci commented Feb 5, 2019

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
Copy link

@swift-ci swift-ci commented Mar 5, 2019

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
Copy link

@swift-ci swift-ci commented Mar 5, 2019

Comment by Borys Gurtovyi (JIRA)

Please, give this bug some attention! Thank you 👍

@swift-ci
Copy link

@swift-ci swift-ci commented Mar 5, 2019

Comment by Johnson Hsieh (JIRA)

This would be great

@swift-ci
Copy link

@swift-ci swift-ci commented Mar 5, 2019

Comment by Nicholas (JIRA)

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

@swift-ci
Copy link

@swift-ci swift-ci commented Mar 5, 2019

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
Copy link

@swift-ci swift-ci commented Mar 5, 2019

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
Copy link

@swift-ci swift-ci commented Mar 5, 2019

Comment by Connor Wybranowski (JIRA)

Would love to see a fix for this! 👍

@slavapestov
Copy link
Member

@slavapestov slavapestov commented Mar 5, 2019

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
Copy link

@swift-ci swift-ci commented Apr 25, 2019

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
Copy link

@swift-ci swift-ci commented May 14, 2019

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
Copy link

@swift-ci swift-ci commented May 14, 2019

Comment by Elliott Williams (JIRA)

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

  1. Run fr v -D 1 to and get a pointer to self

  2. Move up stack frames to get past the frame containing the problematic self reassignment. (in practice, it's easy to move up to `main`)

  3. 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
Copy link

@swift-ci swift-ci commented Oct 4, 2019

Comment by Leonid Kokhnovych (JIRA)

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

@keith
Copy link
Author

@keith keith commented Oct 14, 2020

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 swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug LLDB for Swift
Projects
None yet
Development

No branches or pull requests

5 participants