Navigation Menu

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-7065] REPL broken on Linux (cannot import anything) as of 2018-02-22 Swift 4.1 snapshot #4498

Closed
swift-ci opened this issue Feb 23, 2018 · 19 comments
Labels

Comments

@swift-ci
Copy link

Previous ID SR-7065
Radar rdar://problem/37828364
Original Reporter mason (JIRA User)
Type Bug
Status Resolved
Resolution Done
Environment
  • Ubuntu Server 16.0.4

  • swift-4.1-DEVELOPMENT-SNAPSHOT-2018-02-22-a-ubuntu16.04

Additional Detail from JIRA
Votes 0
Component/s LLDB for Swift
Labels Bug, 4.1Regression
Assignee None
Priority Medium

md5: e080f080c5c634035f438a4193a9b09d

relates to:

  • SR-5524 Importing a modulemapped C library in REPL throws an error
  • SR-6954 Interactive lldb debugging does not work on Linux (regression in Swift 4.1)

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 and CPLUS_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.

developer@ubuntu:/$ sudo mv /swift-4.1-DEVELOPMENT-SNAPSHOT-2018-02-21-a-ubuntu16.04 /swift
developer@ubuntu:/$
developer@ubuntu:/$ which swift
/swift/usr/bin/swift
developer@ubuntu:/$
developer@ubuntu:/$
developer@ubuntu:/$ swift
Welcome to Swift version 4.1-dev (LLVM 1c8b50929b, Clang 420ae40df6, Swift 3152267b41). Type :help for assistance.
  1> import Foundation
  2> ^C
  2> ^D
developer@ubuntu:/$
developer@ubuntu:/$
developer@ubuntu:/$
developer@ubuntu:/$
developer@ubuntu:/$ sudo mv /swift /swift-4.1-DEVELOPMENT-SNAPSHOT-2018-02-21-a-ubuntu16.04
developer@ubuntu:/$
developer@ubuntu:/$ sudo mv /swift-4.1-DEVELOPMENT-SNAPSHOT-2018-02-22-a-ubuntu16.04 /swift
developer@ubuntu:/$
developer@ubuntu:/$ swift
Welcome to Swift version 4.1-dev (LLVM 1c8b50929b, Clang 420ae40df6, Swift d615ce498e). Type :help for assistance.
  1> import Foundation
error: /swift/usr/lib/lldb/clang/5.0.0/include/module.modulemap:24:8: error: redefinition of module '_Builtin_intrinsics'
module _Builtin_intrinsics [system] [extern_c] {
       ^

/swift/usr/lib/swift/clang/include/module.modulemap:24:8: note: previously defined here
module _Builtin_intrinsics [system] [extern_c] {
       ^

error: /swift/usr/lib/lldb/clang/5.0.0/include/module.modulemap:160:8: error: redefinition of module '_Builtin_stddef_max_align_t'
module _Builtin_stddef_max_align_t [system] [extern_c] {
       ^

/swift/usr/lib/swift/clang/include/module.modulemap:160:8: note: previously defined here
module _Builtin_stddef_max_align_t [system] [extern_c] {
       ^

error: /swift/usr/lib/lldb/clang/5.0.0/include/module.modulemap:164:8: error: redefinition of module 'opencl_c'
module opencl_c {
       ^

/swift/usr/lib/swift/clang/include/module.modulemap:164:8: note: previously defined here
module opencl_c {
       ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:8:10: note: in file included from <module-includes>:8:
#include "///usr/include/inttypes.h"
         ^

error: ///usr/include/inttypes.h:290:8: error: unknown type name 'intmax_t'
extern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__));
       ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:8:10: note: in file included from <module-includes>:8:
#include "///usr/include/inttypes.h"
         ^

error: ///usr/include/inttypes.h:290:26: error: unknown type name 'intmax_t'
extern intmax_t imaxabs (intmax_t __n) __THROW __attribute__ ((__const__));
                         ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:8:10: note: in file included from <module-includes>:8:
#include "///usr/include/inttypes.h"
         ^

error: ///usr/include/inttypes.h:293:27: error: unknown type name 'intmax_t'
extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)
                          ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:8:10: note: in file included from <module-includes>:8:
#include "///usr/include/inttypes.h"
         ^

error: ///usr/include/inttypes.h:293:45: error: unknown type name 'intmax_t'
extern imaxdiv_t imaxdiv (intmax_t __numer, intmax_t __denom)
                                            ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:8:10: note: in file included from <module-includes>:8:
#include "///usr/include/inttypes.h"
         ^

error: ///usr/include/inttypes.h:297:8: error: unknown type name 'intmax_t'
extern intmax_t strtoimax (const char *__restrict __nptr,
       ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:8:10: note: in file included from <module-includes>:8:
#include "///usr/include/inttypes.h"
         ^

error: ///usr/include/inttypes.h:301:8: error: unknown type name 'uintmax_t'
extern uintmax_t strtoumax (const char *__restrict __nptr,
       ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:8:10: note: in file included from <module-includes>:8:
#include "///usr/include/inttypes.h"
         ^

error: ///usr/include/inttypes.h:305:8: error: unknown type name 'intmax_t'
extern intmax_t wcstoimax (const __gwchar_t *__restrict __nptr,
       ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:8:10: note: in file included from <module-includes>:8:
#include "///usr/include/inttypes.h"
         ^

error: ///usr/include/inttypes.h:310:8: error: unknown type name 'uintmax_t'
extern uintmax_t wcstoumax (const __gwchar_t *__restrict __nptr,
       ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:28:10: note: in file included from <module-includes>:28:
#include "///usr/include/netdb.h"
         ^

///usr/include/netdb.h:27:10: note: in file included from ///usr/include/netdb.h:27:
#include <netinet/in.h>
         ^

error: /usr/include/netinet/in.h:30:9: error: unknown type name 'uint32_t'
typedef uint32_t in_addr_t;
        ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:28:10: note: in file included from <module-includes>:28:
#include "///usr/include/netdb.h"
         ^

///usr/include/netdb.h:27:10: note: in file included from ///usr/include/netdb.h:27:
#include <netinet/in.h>
         ^

error: /usr/include/netinet/in.h:119:9: error: unknown type name 'uint16_t'
typedef uint16_t in_port_t;
        ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:28:10: note: in file included from <module-includes>:28:
#include "///usr/include/netdb.h"
         ^

///usr/include/netdb.h:27:10: note: in file included from ///usr/include/netdb.h:27:
#include <netinet/in.h>
         ^

error: /usr/include/netinet/in.h:215:2: error: unknown type name 'uint8_t'
        uint8_t __u6_addr8[16];
        ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:28:10: note: in file included from <module-includes>:28:
#include "///usr/include/netdb.h"
         ^

///usr/include/netdb.h:27:10: note: in file included from ///usr/include/netdb.h:27:
#include <netinet/in.h>
         ^

error: /usr/include/netinet/in.h:217:2: error: unknown type name 'uint16_t'
        uint16_t __u6_addr16[8];
        ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:28:10: note: in file included from <module-includes>:28:
#include "///usr/include/netdb.h"
         ^

///usr/include/netdb.h:27:10: note: in file included from ///usr/include/netdb.h:27:
#include <netinet/in.h>
         ^

error: /usr/include/netinet/in.h:218:2: error: unknown type name 'uint32_t'
        uint32_t __u6_addr32[4];
        ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:28:10: note: in file included from <module-includes>:28:
#include "///usr/include/netdb.h"
         ^

///usr/include/netdb.h:27:10: note: in file included from ///usr/include/netdb.h:27:
#include <netinet/in.h>
         ^

error: /usr/include/netinet/in.h:258:5: error: unknown type name 'uint32_t'
    uint32_t sin6_flowinfo;     /* IPv6 flow information */
    ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:28:10: note: in file included from <module-includes>:28:
#include "///usr/include/netdb.h"
         ^

///usr/include/netdb.h:27:10: note: in file included from ///usr/include/netdb.h:27:
#include <netinet/in.h>
         ^

error: /usr/include/netinet/in.h:260:5: error: unknown type name 'uint32_t'
    uint32_t sin6_scope_id;     /* IPv6 scope-id */
    ^

/swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: note: while building module 'SwiftGlibc' imported from /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:
#include <sys/types.h>
         ^

<module-includes>:28:10: note: in file included from <module-includes>:28:
#include "///usr/include/netdb.h"
         ^

///usr/include/netdb.h:27:10: note: in file included from ///usr/include/netdb.h:27:
#include <netinet/in.h>
         ^

error: /usr/include/netinet/in.h:305:5: error: unknown type name 'uint32_t'
    uint32_t gr_interface;
    ^

error: too many errors emitted, stopping now
<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "CoreFoundation.h"
         ^

error: /swift/usr/lib/swift/CoreFoundation/CoreFoundation.h:25:10: error: could not build module 'SwiftGlibc'
#include <sys/types.h>
         ^

/swift/usr/lib/swift/CoreFoundation/CFStream.h:20:10: note: while building module 'CDispatch' imported from /swift/usr/lib/swift/CoreFoundation/CFStream.h:20:
#include <dispatch/dispatch.h>
         ^

<module-includes>:1:10: note: in file included from <module-includes>:1:
#include "dispatch.h"
         ^

/swift/usr/lib/swift/dispatch/dispatch.h:30:10: note: in file included from /swift/usr/lib/swift/dispatch/dispatch.h:30:
#include <os/generic_unix_base.h>
         ^

/swift/usr/lib/swift/os/generic_unix_base.h:17:10: note: in file included from /swift/usr/lib/swift/os/generic_unix_base.h:17:
#include <sys/sysmacros.h>
         ^

error: /usr/include/x86_64-linux-gnu/sys/sysmacros.h:22:10: error: could not build module 'SwiftGlibc'
#include <features.h>
         ^

error: could not build C module 'CoreFoundation'

  1> ^C
  1> ^D
developer@ubuntu:/$
@belkadan
Copy link

*sigh* @adrian-prantl?

(this sigh is not aimed at you, just at complexity)

@adrian-prantl
Copy link
Member

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.

@adrian-prantl
Copy link
Member

@swift-ci create

@belkadan
Copy link

Can you revert the previous commit, then? Right now it is a regression because there was a workaround and now there isn't.

@adrian-prantl
Copy link
Member

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.

@belkadan
Copy link

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.

@swift-ci
Copy link
Author

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.

@adrian-prantl
Copy link
Member

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

@swift-ci
Copy link
Author

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.

Using DEVELOPMENT-SNAPSHOT-2018-03-13

REPL works before changing anything:

@adrian-prantl
Copy link
Member

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 #&#8203;1, name = 'main', stop reason = breakpoint 1.1
    frame #&#8203;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 #&#8203;1, name = 'main', stop reason = step over
    frame #&#8203;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 #&#8203;1, name = 'main', stop reason = breakpoint 1.1
    frame #&#8203;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 #&#8203;1, name = 'main', stop reason = step over
    frame #&#8203;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) 

@adrian-prantl
Copy link
Member

I think that you saw the original symptoms because you still had the C_INCLUDE_PATH workarounds in your environment.

@adrian-prantl
Copy link
Member

Ah. I managed to reproduce what you saw now by adding an `import Foundation` declaration to the source code.

@adrian-prantl
Copy link
Member

However, I can only reproduce that with the snapshot and not with a slightly older swift built from source.

@adrian-prantl
Copy link
Member

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.

@swift-ci
Copy link
Author

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.

@adrian-prantl
Copy link
Member

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)?

@adrian-prantl
Copy link
Member

To clarify: I'm referring to the development snapshot, not to the swift-4.1 snapshot.

@swift-ci
Copy link
Author

Comment by Mason Mark (JIRA)

Above comments answered here

@adrian-prantl
Copy link
Member

This is fixed on trunk / swift-4.2 branch.

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

No branches or pull requests

3 participants