Closed swift-ci closed 6 years ago
*sigh* @adrian-prantl?
(this sigh is not aimed at you, just at complexity)
This is very serious, but since it is no regression, I would like to not attempt to fix this in swift-4.1-branch any more. We clearly need more testing for Linux to catch these problems.
What is happening here is a conflict between the Clang resource directory that is included in LLDB and the one that is included in the Swift compiler. We need to make sure LLDB picks one and only one, and perhaps LLDB should just reuse the one in the swift compiler, but it also seems odd to me for LLDB to depend on clang resources in seemingly unrelated swift compiler. In the future we will want to support one LLDB with many swift compilers so LLDB should carry its own matching clang resources.
@swift-ci create
Can you revert the previous commit, then? Right now it is a regression because there was a workaround and now there isn't.
I'll think about it. Note that the only thing my previous commit did was move the clang resource directory from /usr/share/lldb/clang to /usr/share/lldb/clang/${CLANG_VERSION} which can also easily be undone as part of the workaround.
The previous workaround didn't require moving anything in the toolchain, only setting environment variables.
Additionally, in 4.0, you couldn't import Foundation. Now you can't import anything. That's definitely a regression.
Comment by Mason Mark (JIRA)
Just to make sure I've communicated things clearly and we are all on the same page, let me sum up the timeline:
1.) Swift 4.0.2 RELEASE: Both swift REPL and basic debugging with lldb work fine on Linux, subject to the caveats that you install any missing dependencies (e.g. libcurl3
etc), fix UNIX permissions so that all headers are world readable (CoreFoundation's are the problem), and export the correct values (found in discussion on SR-5524) for C_INCLUDE_PATH
and CPLUS_INCLUDE_PATH
.
The bogus permissions on the headers is obviously a bug (filed as SR-2783), but otherwise this could be considered a documentation bug. Once known, it is easy to workaround. (IIRC this also worked back to Swift 3.1 but I'm not totally sure.)
2.) Swift 4.1 2018-02-21 snapshot and prior: Swift REPL works fine, but debugging with lldb does not. I am not sure when this started, but I filed SR-6954 as soon as I hit that issue.
3.) Swift 4.1 2018-02-22: Debugging with lldb does now work, but the REPL no longer works. That's this issue, SR-7065.
If there is a workaround the end user can reasonably apply, after downloading and installing Swift 4.1, then this is not the end of the world, and maybe not really any worse than 4.0.2. Like if it is setting some env vars and/or adding some symlinks, or something like that.
OTOH if the workaround involves the end user having to make changes and rebuild Swift, that's a fairly serious regression.
From a day-to-day development perspective (development of things written in Swift, I mean, not of Swift itself), having to choose between the REPL and the debugger is a really tough call. They are both important.
I guess if forced to choose, though, I'd choose a broken REPL over a broken debugger, though, because although the REPL probably gets used a lot more, when you really need lldb you really need it.
I can't actually get this to reproduce when building the toolchain from source.
Can you reproduce this using the following instructions? (This basically re-applies the fix from https://bugs.swift.org/browse/SR-6954)
If it does reproduce for you: What do you have in your environment?
cd /tmp/
wget https://swift.org/builds/development/ubuntu1604/swift-DEVELOPMENT-SNAPSHOT-2018-03-13-a/swift-DEVELOPMENT-SNAPSHOT-2018-03-13-a-ubuntu16.04.tar.gz
tar xzf swift-DEVELOPMENT-SNAPSHOT-2018-03-13-a-ubuntu16.04.tar.gz
mkdir swift-DEVELOPMENT-SNAPSHOT-2018-03-13-a-ubuntu16.04/usr/lib/lldb/clang/5.0.0
mv swift-DEVELOPMENT-SNAPSHOT-2018-03-13-a-ubuntu16.04/usr/lib/lldb/clang/include swift-DEVELOPMENT-SNAPSHOT-2018-03-13-a-ubuntu16.04/usr/lib/lldb/clang/5.0.0/include
swift-DEVELOPMENT-SNAPSHOT-2018-03-13-a-ubuntu16.04/usr/bin/swift
1> import Foundation
Comment by Mason Mark (JIRA)
Thanks, @adrian-prantl. I tried your instructions with DEVELOPMENT-SNAPSHOT-2018-03-13
and the REPL can successfully import Foundation
in either case. It works before I move the include
dir, and it works after I move it.
So, I also cannot reproduce this issue with this snapshot.
I also note that lldb does not work before the directory is moved (the same symptoms as SR-6954) but after the include
directory is moved per your instructions, it seems like it is trying to work. It actually fails but the failure looks to me like a different issue. Just in case it's helpful I append my complete output below. Cheers.
I can't reproduce the lldb failure.
$ _install/usr/bin/lldb /tmp/main
(lldb) target create "/tmp/main"
Current executable set to '/tmp/main' (x86_64).
(lldb) b main
Breakpoint 1: where = main`main + 30 at main.swift:1, address = 0x0000000000000e5e
(lldb) r
Process 54778 launched: '/tmp/main' (x86_64)
Process 54778 stopped
* thread #​1, name = 'main', stop reason = breakpoint 1.1
frame #​0: 0x0000555555554e5e main`main at main.swift:1
-> 1 let output = "This is some text output."
2 print("1. " + output)
3 print("2. " + output)
4
Target 0: (main) stopped.
(lldb) n
Process 54778 stopped
* thread #​1, name = 'main', stop reason = step over
frame #​0: 0x0000555555554e87 main`main at main.swift:2
1 let output = "This is some text output."
-> 2 print("1. " + output)
3 print("2. " + output)
4
Target 0: (main) stopped.
(lldb) po output
"This is some text output."
or with the snapshot:
/tmp/adrian/swift-DEVELOPMENT-SNAPSHOT-2018-03-13-a-ubuntu16.04/usr/bin/lldb /tmp/main
(lldb) target create "/tmp/main"
Current executable set to '/tmp/main' (x86_64).
(lldb) b main
Breakpoint 1: where = main`main + 30 at main.swift:1, address = 0x0000000000000dce
(lldb) r
Process 54992 launched: '/tmp/main' (x86_64)
Process 54992 stopped
* thread #​1, name = 'main', stop reason = breakpoint 1.1
frame #​0: 0x0000555555554dce main`main at main.swift:1
-> 1 let output = "This is some text output."
2 print("1. " + output)
3 print("2. " + output)
4
Target 0: (main) stopped.
(lldb) n
Process 54992 stopped
* thread #​1, name = 'main', stop reason = step over
frame #​0: 0x0000555555554df7 main`main at main.swift:2
1 let output = "This is some text output."
-> 2 print("1. " + output)
3 print("2. " + output)
4
Target 0: (main) stopped.
(lldb) po output
"This is some text output."
(lldb)
I think that you saw the original symptoms because you still had the C_INCLUDE_PATH workarounds in your environment.
Ah. I managed to reproduce what you saw now by adding an `import Foundation` declaration to the source code.
However, I can only reproduce that with the snapshot and not with a slightly older swift built from source.
I have yet to find the combination of LangOptions and configuration macros that reproduces this exact error message when compiling the overlay module with clang alone. I'm rebuilding today's toolchain from source now.
Comment by Mason Mark (JIRA)
Update: I tried again today, following @adrian-prantl's instructions above for moving the "include" directory, but with the Swift 4.1 March 26, 2018 snapshot. With that snapshot, before moving the directory, the REPL worked (this issue SR-7065 seems fixed), but lldb debugging did not work (SR-6954 is back). However, after moving the directory per those instructions, the REPL worked and lldb debugging also worked (both issues fixed).
So it seems like moving the directory did fix the issue, and the lldb issue I saw on March 16 above was, in fact, some other issue.
mason (JIRA User): The workaround you are mentioning is part of the current master branch. Can you confirm that this works as expected using the latest snapshot (Ubuntu 16.04)?
To clarify: I'm referring to the development snapshot, not to the swift-4.1 snapshot.
This is fixed on trunk / swift-4.2 branch.
Environment
- Ubuntu Server 16.0.4 - swift-4.1-DEVELOPMENT-SNAPSHOT-2018-02-22-a-ubuntu16.04Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 0 | |Component/s | LLDB for Swift | |Labels | Bug, 4.1Regression | |Assignee | None | |Priority | Medium | md5: e080f080c5c634035f438a4193a9b09drelates to:
Issue Description:
There is a regression in the Swift 4.1 2018-02-22 snapshot for Linux that causes the REPL to fail on Linux. Failure occurs when importing anything, e.g.
import Foundation
.Although the REPL hasn't worked on Linux "out of the box" since at least 3.1, it has been reliable if you apply the workarounds from the discussion of SR-2783 and SR-5524 (namely, manually fix header permissions, and manually export
C_INCLUDE_PATH
andCPLUS_INCLUDE_PATH
).However, these workarounds are no longer sufficient in the 2018-02-22 Swift 4.1 snapshot. As the complete transcript below shows, using the 2018-02-21 snapshot, doing `import Foundation` in the REPL works as expected; using the 2018-02-22 it does not work.
The error messages it spews are very similar to those seen in SR-5524. I would also note that there was a recent fix for debugging on Linux using lldb, SR-6954, which also involved very similar error output (only in lldb, and not the Swift REPL itself). That issue was recently fixed, and lldb debugging on Linux works as of the 2018-02-22 snapshot. Which is the snapshot where the REPL broke on Linux, and makes me suspect that this new issue with the REPL relates to the fix implemented for SR-6954, although that is just a guess.
The transcript below illustrates the problem; the REPL is working with the 2018-02-21 Swift 4.1 snapshot, and failing with the 2018-02-22 snapshot.