Skip to content
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.

Linux support #16

Closed
wants to merge 10 commits into from
Closed

Linux support #16

wants to merge 10 commits into from

Conversation

heckj
Copy link
Contributor

@heckj heckj commented Apr 28, 2020

WIP to address #1

(process note: I'm editing with Xcode, but testing on linux leveraging the swift-docker mechanism that Iain Smith recently crafted. Interactive local tests (assuming you have docker and the tooling installed) can be run with:

swift docker test --args --enable-test-discovery

@heckj
Copy link
Contributor Author

heckj commented Apr 28, 2020

Debugging notes from my lunch break:

  • compilation under swift within a container (the swift build bit before testing) is pretty consistently failing at some point - unknown why. Re-running gets past it with swift docker test --args --enable-test-discovery, as it retains the partial compilation and picks up where it left off.

I also have Dockerfiles for Swift 5.0, 5.1, and 5.2 in Linux added. I added each to see if there was a difference in output for the different flavors of swift 5. (this is temp!) - 5.0 doesn't support the --enable-test-discovery stuff, which can be worked around but is annoying, but 5.1 and 5.2 both consistently fail. Using either of these is a "from scratch" build and test sequence, and none of them are getting past the build portion of them. They're failing when doing the C compilation of swift-syntax:

 ---> Running in 0874ddcdbd79
Fetching https://github.com/apple/swift-syntax.git
Fetching https://github.com/SwiftDocOrg/TAP.git
Fetching https://github.com/kean/Future
Fetching https://github.com/apple/swift-argument-parser.git
Fetching https://github.com/jpsim/Yams.git
Cloning https://github.com/SwiftDocOrg/TAP.git
Resolving https://github.com/SwiftDocOrg/TAP.git at 0.1.1
Cloning https://github.com/kean/Future
Resolving https://github.com/kean/Future at 1.4.0
Cloning https://github.com/apple/swift-argument-parser.git
Resolving https://github.com/apple/swift-argument-parser.git at 0.0.5
Cloning https://github.com/jpsim/Yams.git
Resolving https://github.com/jpsim/Yams.git at 3.0.0
Cloning https://github.com/apple/swift-syntax.git
Resolving https://github.com/apple/swift-syntax.git at 0.50200.0
[1/24] Compiling writer.c
[2/24] Compiling atomic-counter.c
[3/26] Compiling reader.c
[4/60] Compiling api.c
[5/82] Compiling parser.c
[6/93] Compiling emitter.c
[7/93] Compiling scanner.c
The command '/bin/sh -c swift test --enable-test-discovery' returned a non-zero code: 1

In my next debugging session, I'm going to see if I can narrow down both this compilation issue and what's happening with the REPL. When using swift docker test --args --enable-test-discovery it's clear the output isn't ever coming back to get evaluated from the underlying process that's been invoked, and additionally I'm seeing a fairly repeatable error with ContiguousArray hitting an index out of bounds scenario, the stack trace of which is exploding down in the Standard Library - but I'm not sure of the root cause there either.

  Test Suite 'All tests' started at 2020-04-28 19:20:44.226
  Test Suite 'debug.xctest' started at 2020-04-28 19:20:44.228
  Test Suite 'DocTestTests' started at 2020-04-28 19:20:44.228
  1 FROM swift:5.1
  Test Case 'DocTestTests.testRunner' started at 2020-04-28 19:20:44.228
Fatal error: Index out of range: file /home/buildnode/jenkins/workspace/oss-swift-5.2-package-linux-ubuntu-18_04/swift/stdlib/public/core/ContiguousArrayBuffer.swift, line 444
  sending statement for evaluation: Statement('1 + 1' at location: 1:1Current stack trace:

  sending statement for evaluation: Statement('1 + 1' at location: 1:7
  sending statement for evaluation: Statement('1 / 0' at location: 2:7
  closing REPL
  waiting for REPL process to terminate0    libswiftCore.so                    0x00007f40cc29df90 swift_reportError + 50

  /package/Tests/DocTestTests/DocTestTests.swift:20: error: DocTestTests.testRunner : XCTAssertEqual failed: ("0") is not equal to ("3") -
1    libswiftCore.so                    0x00007f40cc30fa60 _swift_stdlib_reportFatalErrorInFile + 115
2    libswiftCore.so                    0x00007f40cc024735 <unavailable> + 1382197
3    libswiftCore.so                    0x00007f40cc024257 <unavailable> + 1380951
4    libswiftCore.so                    0x00007f40cc023f23 <unavailable> + 1380131
5    libswiftCore.so                    0x00007f40cc023890 _assertionFailure(_:_:file:line:flags:) + 525
6    libswiftCore.so                    0x00007f40cc009ed0 Array.subscript.getter + 123
7    DocTestPackageTests.xctest         0x000055d75931194c <unavailable> + 772428
8    DocTestPackageTests.xctest         0x000055d75931229f <unavailable> + 774815
9    libXCTest.so                       0x00007f40cc574730 XCTAssertTrue(_:_:file:line:) + 38  Exited with signal code 4

  1 FROM swift:5.1
10   DocTestPackageTests.xctest         0x000055d7593115f5 <unavailable> + 771573
  1 FROM swift:5.2
11   DocTestPackageTests.xctest         0x000055d75930989d <unavailable> + 739485
12   DocTestPackageTests.xctest         0x000055d759311001 <unavailable> + 770049
  1 FROM swift:5.0
13   DocTestPackageTests.xctest         0x000055d759310c79 <unavailable> + 769145
14   DocTestPackageTests.xctest         0x000055d759310a5f <unavailable> + 768607
15   DocTestPackageTests.xctest         0x000055d759310c64 <unavailable> + 769124
16   libXCTest.so                       0x00007f40cc56dfd1 <unavailable> + 200657
17   libXCTest.so                       0x00007f40cc56ddde <unavailable> + 200158
18   libXCTest.so                       0x00007f40cc56dd64 <unavailable> + 200036
19   libXCTest.so                       0x00007f40cc56e0a9 <unavailable> + 200873
20   libXCTest.so                       0x00007f40cc55f4e7 <unavailable> + 140519
21   libXCTest.so                       0x00007f40cc56bef0 XCTestCase.invokeTest() + 55
22   libXCTest.so                       0x00007f40cc56bbc0 XCTestCase.perform(_:) + 157
23   libXCTest.so                       0x00007f40cc570530 XCTest.run() + 150
24   libXCTest.so                       0x00007f40cc56e2e0 XCTestSuite.perform(_:) + 160
25   libXCTest.so                       0x00007f40cc570530 XCTest.run() + 150
26   libXCTest.so                       0x00007f40cc56e2e0 XCTestSuite.perform(_:) + 160
27   libXCTest.so                       0x00007f40cc570530 XCTest.run() + 150
28   libXCTest.so                       0x00007f40cc56e2e0 XCTestSuite.perform(_:) + 160
29   libXCTest.so                       0x00007f40cc570530 XCTest.run() + 150
30   libXCTest.so                       0x00007f40cc569da0 XCTMain(_:) + 1524
31   DocTestPackageTests.xctest         0x000055d759310d51 <unavailable> + 769361
32   libc.so.6                          0x00007f40c98faab0 __libc_start_main + 231
33   DocTestPackageTests.xctest         0x000055d7592d482a <unavailable> + 522282

@heckj
Copy link
Contributor Author

heckj commented Apr 29, 2020

I've added Dockerfiles for swift 5.0, 5.1 and 5.2 - 5.0 doesn't do "--enable-test-discovery", which ends up being an annoyance. In breaking those up, I've identified that when swift build is invoked (5.1 & 5.2), the build will sometimes file when the automatic indexing is enabled alongside it. It runs smoothly if you pass in --disable-index-store.

The same applies for the tests, and unfortunately the whole thing about test discovery appears to rely on having that index store operating at the same time as the tests are compiling.

For the current segment of this branch, you can use the following command to do the initial building and then drop you into an interactive terminal session inside the container:

docker build . -f Dockerfile_5.2 -t linuxbuild52 --no-cache && docker run --rm -it linuxbuild52

From there, running swift test --enable-test-discovery will eventually work, but may take a time or two at the compilation due to whatever this failure is where it's blowing up while the index-store processing is happening at the same time.

I'm still not 100% clear on if this is related to the error we're seeing in the test output itself, where it's throwing an expiation with an array out of bounds. The current fatal error being thrown:

Fatal error: Index out of range: file /home/buildnode/jenkins/workspace/oss-swift-5.2-package-linux-ubuntu-18_04/swift/stdlib/public/core/ContiguousArrayBuffer.swift, line 444

It seems implausible that there's an error the standard library, but maybe there's a very unexpected interaction within XCTest and the stdlib when being invoked on Linux. I may well hit the OSS forums and share what I've learned and ask for open ended advice there...

@heckj
Copy link
Contributor Author

heckj commented Apr 29, 2020

morning coffee debugging note:

  • The compilation failure didn't repeat itself in the same way on another host system, so there may be something about my local setup that was impacting that - I've set that pretty much to the side as a separate issue. It was impacted by to allowing the "index store" to run in parallel with the build, but not repeatable on another host platform.
  • The swiftly capability '--enable-test-discovery' requires the build system to be operating and using the index store.
  • The error which I was seeing earlier about the contiguous array and the fatalError with array out of bounds went away when I ran everything within a docker container with looser security constraints, and in fact the tests all passed correctly. The error/issue in the tests operating seems to be related to these security constraints:
--cap-add=SYS_PTRACE --security-opt seccomp=unconfined --security-opt apparmor=unconfined

as a side note, my local docker instance would not allow me to run reduce these security constraints while running doing a "docker build", so the path for checking on this appears to require setting up a container, loading the source into it, and then running it with the lower security constraints in order to run the tests. The short-cut trick of setting it all up within the docker build . command runs afoul.

@heckj
Copy link
Contributor Author

heckj commented Apr 29, 2020

Narrowed it down - apparently the REPL that is used underneath all this is specifically dependent on the security constraint being loosened: --security-opt seccomp=unconfined. Reference to Ankit talking about the REPL in the swift forums about this.

@heckj
Copy link
Contributor Author

heckj commented Apr 29, 2020

closing in favor of Matt's update in #17

@heckj heckj closed this Apr 29, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant