Open swift-ci opened 5 years ago
CC @nkcsgexi
@belkadan not sure what exactly the 'Compiler Crash' label is for but this isn't a real crash, this is someone killing the process with SIGKILL
. Most likely it's the kernel because of out of memory I'd think.
It's a crash in practice, even if it's not literally an assertion failure or segfault.
cool, that makes sense
I was not able to reproduce in any setup I have at hand. I tried:
Swift docker images for 5.0.1 bionic and xenial
I tried again, but with memory limited to 1.5 GB
macOS, and I watched the memory use; it never seemed to go over a couple hundred MB per job
I think we'll need more information to investigate this, for example:
what is the specific command that is failing? You could try adding `-v -Xswiftc -v` to the build to see the invocations
if this is running out of memory, how much memory is the swift process actually using?
Comment by tanner0101 (JIRA)
Here's a link to a PR that will trigger the error in ci:
https://github.com/vapor/crypto-kit/pull/93
Here's a link to the failed build:
https://circleci.com/gh/vapor/crypto-kit/1364?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
The command being run:
swift build -v -Xswiftc -v -Xcc -v -Xlinker -v -Xcxx -v
Resources for this machine:
2CPU/4096MB
The end of the output:
clang -cc1 version 7.0.0 based upon LLVM 7.0.0svn default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "//include"
#include "..." search starts here:
#include <...> search starts here:
/root/project/.build/x86_64-unknown-linux/debug
/root/project/Sources/CBcrypt/include
/root/project/Sources/CBase32/include
/usr/lib/swift
//usr/local/include
/usr/lib/swift/clang/include
//usr/include/x86_64-linux-gnu
//usr/include
End of search list.
<unknown>:0: error: unable to execute command: Killed
<unknown>:0: error: compile command failed due to signal 9 (use -v to see invocation)
Exited with code 1
FWIW, I think it is something specific to CircleCI. Perhaps some breach of permissions? The only way I could recreate this locally using Docker was to limit memory very low--about 100M.
But if I SSH into the CircleCI container and run `swift build` (clean, no artifacts) it happens every time.
One thing I noticed in the log is "-j36" in the original build command; maybe swiftpm is detecting the number of cores incorrectly? Does it still fail if you pass `-Xswiftc -j2` or `-Xswiftc -j1`?
ah, this is likely a container CPUs vs. host machine CPUs.
Comment by Sergej Jaskiewicz (JIRA)
I'm experiencing this exact issue, have you been able to find a workaround tannernelson (JIRA User)?
Right now I'm just rerunning the whole `swift build` command, which is suboptimal.
Environment
The system is a CircleCI box running Ubuntu 16.04 with 2CPU/4096M. Swift version 5.0.1 (swift-5.0.1-RELEASE) Target: x86_64-unknown-linux-gnu Linux 7b81119c92aa 4.15.0-1035-aws \#37-Ubuntu SMP Mon Mar 18 16:15:14 UTC 2019 x86_64 x86_64 x86_64 GNU/LinuxAdditional Detail from JIRA
| | | |------------------|-----------------| |Votes | 1 | |Component/s | Compiler, Source Tooling | |Labels | Bug, CompilerCrash | |Assignee | None | |Priority | Medium | md5: a83f0d011f237654ef4bad38a340045dIssue Description:
Attempting to compile this SPM project causes signal 9:
https://github.com/vapor/crypto/tree/e60bc60b74b9b976800a44369e1067180fa59cba
Using --disable-index-store fixes the issue
Building with -c release does not exhibit the issue.
Running swift build a second time, after the initial failure (without clearing .build), works