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.

Sign up for GitHub

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

Jump to bottom

Latest nightly crashes on centos 5 #56849

Closed
konstin opened this issue Dec 15, 2018 · 7 comments · Fixed by #56892
Closed

Latest nightly crashes on centos 5 #56849

konstin opened this issue Dec 15, 2018 · 7 comments · Fixed by #56892
Labels
regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.

Comments

@konstin
Copy link

konstin commented Dec 15, 2018

This can be reproduced in a centos 5 docker container, such as the one provided by python's pypa:

docker run -it quay.io/pypa/manylinux1_x86_64 bash

curl https://sh.rustup.rs -sSf | sh -s -- -y --default-toolchain nightly
source $HOME/.cargo/env
rustup toolchain add stable
cargo new hello-world
cd hello-world
cargo +stable build # This works
cargo build # This crashes

The last command produces the following error:

error: process didn't exit successfully: `rustc -vV` (exit code: 1)
--- stdout
rustc 1.33.0-nightly (96d1334e5 2018-12-14)
binary: rustc
commit-hash: 96d1334e567237b1507cd277938e7ae2de75ff51
commit-date: 2018-12-14
host: x86_64-unknown-linux-gnu
release: 1.33.0-nightly

--- stderr
error: couldn't load codegen backend "/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so": "/lib64/libgcc_s.so.1: version `GCC_4.3.0\' not found (required by /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so)"

Versions:

cat /etc/redhat-release: CentOS release 5.11 (Final)
cargo -V: cargo 1.33.0-nightly (2cf1f5dda 2018-12-11)
rustc -V: rustc 1.33.0-nightly (96d1334e5 2018-12-14)
rustc -vV: crashes with the same output as above
@konstin konstin mentioned this issue Dec 15, 2018
Closed
@sfackler sfackler added T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Dec 15, 2018
@memoryruins memoryruins mentioned this issue Dec 15, 2018
Closed
@alexcrichton
Copy link
Member

Some bisection reveals that this is a regression from #56051 actually, and I suspect the most likely candidate of that rollup is #55952

cc @michaelwoerister

As to why these symbols are just now showing up, I'm not sure...

@alexcrichton
Copy link
Member

Ok I've confirmed #55952 is the cause of this bug. I don't really know how this is showing up though as none of the symbols which use GCC_4.3.0 are even referenced from the file:

$ readelf -s obj/build/x86_64-unknown-linux-gnu/llvm/bin/llc | grep GCC_4.3.0
   343: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatuntitf@GCC_4.3.0 (12)
   344: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __netf2@GCC_4.3.0 (12)
   346: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatunditf@GCC_4.3.0 (12)
   347: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __multf3@GCC_4.3.0 (12)
   350: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixtfdi@GCC_4.3.0 (12)
   351: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __eqtf2@GCC_4.3.0 (12)
   353: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __powitf2@GCC_4.3.0 (12)
   354: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatunsitf@GCC_4.3.0 (12)
   355: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatditf@GCC_4.3.0 (12)
   356: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixtfti@GCC_4.3.0 (12)
   357: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __lttf2@GCC_4.3.0 (12)
   358: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __extendsftf2@GCC_4.3.0 (12)
   361: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __letf2@GCC_4.3.0 (12)
   363: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __extenddftf2@GCC_4.3.0 (12)
   365: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixunstfti@GCC_4.3.0 (12)
   367: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixtfsi@GCC_4.3.0 (12)
   370: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __gttf2@GCC_4.3.0 (12)
   371: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __addtf3@GCC_4.3.0 (12)
   374: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __divtf3@GCC_4.3.0 (12)
   377: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __extendxftf2@GCC_4.3.0 (12)
   378: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __trunctfdf2@GCC_4.3.0 (12)
   382: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __trunctfxf2@GCC_4.3.0 (12)
   383: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixunstfdi@GCC_4.3.0 (12)
   385: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __unordtf2@GCC_4.3.0 (12)
   389: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __getf2@GCC_4.3.0 (12)
   390: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __fixunstfsi@GCC_4.3.0 (12)
   391: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floattitf@GCC_4.3.0 (12)
   394: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __floatsitf@GCC_4.3.0 (12)
   395: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __subtf3@GCC_4.3.0 (12)
   396: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __trunctfsf2@GCC_4.3.0 (12)

None of those symbols are even used from llc or LLVM or... anywhere it seems. I have no idea what's putting that into some symbol table that needs to be resolved.

This may be some LLD change though because if I disable ThinLTO for LLVM itself then these symbol references seem to go away...

@alexcrichton
Copy link
Member

Ok I've bisected this to rust-lang/lld@103b4dc, which makes sense sort of because that's injecting references to all builtins, even if we're not actually using them.

I'll follow up with LLVM later tomorrow

@alexcrichton
Copy link
Member

Or actually, I've gone ahead and opened an upstream bug report to get the ball rolling there.

This is also a beta regression as well, so I'm retagging as such.

I believe the only solution we have for now on this is to turn off ThinLTO, so I'm going to send a PR to do that.

@alexcrichton alexcrichton added regression-from-stable-to-beta Performance or correctness regression from stable to beta. and removed regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. labels Dec 16, 2018
alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 16, 2018
@alexcrichton
rustc: Disable ThinLTO for LLVM's build
f905579 
This commit goes back to disabling ThinLTO for building LLVM and its
tools. It turns out that this caused a regression at rust-lang#56849 which I
believe we'll definitely want to fix before it goes live. The bisection
turned up an [upstream LLVM bug][bug], so hopefully there'll eventually
be a fix we can backport.

I've also been a little uneasy about how we're only enabling ThinLTO for
LLVM on Linux, and we haven't had a chance to turn it on for OSX and
Windows (other "Tier 1" platforms) yet. Additionally it had an
unexpected hit to CI time we never got around to fixing. I'd ideally
prefer that we fix these issues as well before re-landing.

Closes rust-lang#56849

[bug]: https://bugs.llvm.org/show_bug.cgi?id=40045
@alexcrichton alexcrichton mentioned this issue Dec 16, 2018
Closed
@alexcrichton
Copy link
Member

Er turns out this is likely already fixed at llvm-mirror/lld@3be4e82, so I can try out building that locally

alexcrichton added a commit to alexcrichton/rust that referenced this issue Dec 16, 2018
@alexcrichton
rustc: Update Clang used to build LLVM on LInux
bbce189 
This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld
to build LLVM on our dist builders for Linux. The goal of this is to
fix rust-lang#56849 by picking up a fix [1] in LLD.

Closes rust-lang#56849

[1]: llvm-mirror/lld@3be4e82
This was referenced Dec 16, 2018
Merged
Merged
pietroalbini added a commit to pietroalbini/rust that referenced this issue Dec 20, 2018
@pietroalbini
Rollup merge of rust-lang#56892 - alexcrichton:new-llvm, r=michaelwoe…
e801ffa 
…rister

rustc: Update Clang used to build LLVM on Linux

This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld
to build LLVM on our dist builders for Linux. The goal of this is to
fix rust-lang#56849 by picking up a fix [1] in LLD.

Closes rust-lang#56849

[1]: llvm-mirror/lld@3be4e82
@ijl ijl mentioned this issue Dec 20, 2018
Closed
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Dec 21, 2018
@Mark-Simulacrum
Rollup merge of rust-lang#56892 - alexcrichton:new-llvm, r=michaelwoe…
b98afee 
…rister

rustc: Update Clang used to build LLVM on Linux

This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld
to build LLVM on our dist builders for Linux. The goal of this is to
fix rust-lang#56849 by picking up a fix [1] in LLD.

Closes rust-lang#56849

[1]: llvm-mirror/lld@3be4e82
pietroalbini added a commit to pietroalbini/rust that referenced this issue Dec 21, 2018
@pietroalbini
Rollup merge of rust-lang#56892 - alexcrichton:new-llvm, r=michaelwoe…
2cd3b95 
…rister

rustc: Update Clang used to build LLVM on Linux

This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld
to build LLVM on our dist builders for Linux. The goal of this is to
fix rust-lang#56849 by picking up a fix [1] in LLD.

Closes rust-lang#56849

[1]: llvm-mirror/lld@3be4e82
Centril added a commit to Centril/rust that referenced this issue Dec 22, 2018
@Centril
Rollup merge of rust-lang#56892 - alexcrichton:new-llvm, r=michaelwoe…
c2ed5cc 
…rister

rustc: Update Clang used to build LLVM on Linux

This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld
to build LLVM on our dist builders for Linux. The goal of this is to
fix rust-lang#56849 by picking up a fix [1] in LLD.

Closes rust-lang#56849

[1]: llvm-mirror/lld@3be4e82
bors added a commit that referenced this issue Dec 23, 2018
@bors
Auto merge of #56892 - alexcrichton:new-llvm, r=michaelwoerister
ddab10a 
rustc: Update Clang used to build LLVM on Linux

This commit updates from LLVM 7.0.0 to git revisions of clang/llvm/lld
to build LLVM on our dist builders for Linux. The goal of this is to
fix #56849 by picking up a fix [1] in LLD.

Closes #56849

[1]: llvm-mirror/lld@3be4e82
@evanjs evanjs mentioned this issue Jan 7, 2019
Closed
@konstin
Copy link
Author

konstin commented Jan 8, 2019

This seems to have regressed again: https://travis-ci.org/PyO3/pyo3-pack/jobs/476983489 with this Dockerfile: https://github.com/PyO3/pyo3-pack/blob/master/Dockerfile

Relevant excerpt:

error: process didn't exit successfully: `rustc -vV` (exit code: 1)
--- stdout
rustc 1.33.0-nightly (8e2063d02 2019-01-07)
binary: rustc
commit-hash: 8e2063d02062ee9f088274690a97826333847e17
commit-date: 2019-01-07
host: x86_64-unknown-linux-gnu
release: 1.33.0-nightly
--- stderr
error: couldn't load codegen backend "/root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/librustc_codegen_llvm-llvm.so": "/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9\' not found (required by /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/../lib/libLLVM-8svn.so)"

@alexcrichton
Copy link
Member

Indeed! This should be fixed in #57429

@joar joar mentioned this issue Jan 9, 2019
Open
joar added a commit to joar/rust-csv-py that referenced this issue Jan 10, 2019
@joar
Go back to nightly
561448c 
I believe rust-lang/rust#56849 has been
released now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
regression-from-stable-to-beta Performance or correctness regression from stable to beta. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
3 participants
@alexcrichton @sfackler @konstin