Opened 3 years ago

Closed 3 years ago

#11521 closed enhancement (fixed)

Upgrade rustc for firefox-65.0

Reported by: ken@… Owned by: Bruce Dubbs
Priority: normal Milestone: 8.4
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

Firefox-65.0 is expected to be released on 20th January, after a "soft freeze" on 21st January. It will need at least version 1.30 of rust. As in past practice, we should prefer the latest version.

The 1.30 series was first released on 6th December (point release on about 20th December) which suggests that 1.32.0 will be released around the 23rd January because the minor versions seem to be on a 7-week cycle.

We can probably use 1.31.1, but never trust release schedules! (there might be late changes somewhere which require a later version).

Change History (43)

comment:1 by ken@…, 3 years ago

Owner: changed from blfs-book to ken@…
Status: newassigned

comment:2 by Bruce Dubbs, 3 years ago

According to that paragon of correct information, slashdot, rustc-1.32.0 was released last Thursday.

$ du -sh rustc-1.32.0-src.tar.gz 152M rustc-1.32.0-src.tar.gz $ md5sum rustc-1.32.0-src.tar.gz 366f049777e00d0d6f15d25895485efb rustc-1.32.0-src.tar.gz

comment:3 by ken@…, 3 years ago

Indeed it was, and it showed up in your daily version check.

On my ryzen (which is the most up-to-date system), this is giving me a lot more grief than 1.31.0. Specifically, a lot of segmentation faults in the tests (in lto tests), and then current firefox-beta (65.0b11) fails to build in gkrust with a segfault.

Retrying, just in case, was no different. Tried *forcing* thinlto in llvm (that might be the default now, but it looks as if the build might be slightly smaller) which reduced 23 failures to 22.

Meanwhile, on an old phenom running mostly BLFS-8.3 it seemed fine (only 4 test failures, three of which are for thumb (ARM) compiler variants) and successfully built firefox-64.0.2.

Short current status: severely broken on *my* ryzen, on other machines the test results might be a lot better than previous versions (e.g. it seems to be ok in gdb tests, and to skip those if gdb is not present). Currently trying with system llvm upgraded to 7.0.1 on the ryzen, that doesn't seem to make any odds (still the segfaults in the tests), but will retry firefox later to be sure.

Meanwhile, earlier in the week I completed testing 1.31.0 with all its users (firefox-release as well as beta, thunderbird, librsvg, and running the gdb testsuite (ambivalent, but didn't seem to be worse than with 1.29).

One, or perhaps two, other things to try - I see that gentoo and Arch do not appear to have problems although neither have beta (source). I also don't know if the segmentation fault in building firefox on this machine also applies to 64.0.2.

I'm seriously thinking about giving up on this and learning to love binary distros. If I can't get anywhere, will reinstall 1.31.0 and see if the segfaults are because some RAM has decided to fail.

comment:4 by Douglas R. Reno, 3 years ago

Ken,

I've got a system with a AMD Phenom X2 521 in it that's not being used for anything at the moment (it's been sitting dormant for a couple months now). I don't currently have LFS/BLFS on it, but I could put it on it if the results would assist you at all. I just don't know what I'd use it for afterwards - just run stable BLFS on it?

Either way, if you want - I can get it going to get results for you. Here are links to it's specs (although I've upgraded the RAM):

https://support.hp.com/us-en/document/c02863024

I'll need help finding firmware for it though. OTOH, I suppose I could use it for testing the AMD/ATI drivers at release time...

in reply to:  4 comment:5 by ken@…, 3 years ago

Replying to renodr:

Ken,

I've got a system with a AMD Phenom X2 521 in it that's not being used for anything at the moment (it's been sitting dormant for a couple months now). I don't currently have LFS/BLFS on it, but I could put it on it if the results would assist you at all. I just don't know what I'd use it for afterwards - just run stable BLFS on it?

Either way, if you want - I can get it going to get results for you. Here are links to it's specs (although I've upgraded the RAM):

https://support.hp.com/us-en/document/c02863024

I'll need help finding firmware for it though. OTOH, I suppose I could use it for testing the AMD/ATI drivers at release time...

Thanks, but no thanks. My own phenom is a II x4 965 (no idea how they compare) and from time to time it loses its lunch and segfaults, probably because the motherboard is not supplying adequate voltage for the memory. But that machine (after dropping the caches, because of its general segfaults) built 64.0.2 without problems. The problem seems to be specific to ryzens, or even (given the lack of other reports on the previous firefox bug) specific to _my_ ryzen. Currently seeing if it can build 64.0.2 with 1.32.0, but not optimistic.

My impression is that most people building on ryzens are using binary versions of rust, so if there is a problem it will take some time to become apparent. Meanwhile, the build farms at mozilla and at distros are probably mostly intel or very old (FX) AMD.

The key underlying problem, in my view, is that ryzen dropped a few opcodes, e.g. using binaries from a Fam15h Kaveri (before that started to die) failed to build.

comment:6 by ken@…, 3 years ago

I am hopeful that the problem is caused by using system llvm. There is an issue for rust where Arch's system llvm is blamed.

So, I tried building with the shipped llvm, and also for target ARM (to try to get clean test results by not failing the thumb tests). No reported segmentation faults (in practice, I still had a couple, plus 5 traps - the original ryzen problem), one test failure reported:

    [run-make] run-make-fulldeps/sysroot-crates-are-unstable

which I have seen before and is the fourth failure on the other system.

Unfortunately, cannot build firefox:

 0:05.98 checking rustc version... 1.32.0
 0:06.03 checking cargo version... 1.32.0
 0:06.35 DEBUG: <truncated - see config.log for full output>
[...] 0:06.35 DEBUG: | error[E0514]: found crate `std` compiled by an incompatible version of rustc
 0:06.35 DEBUG: |   |
 0:06.35 DEBUG: |   = help: please recompile that crate using this compiler (rustc 1.32.0)
 0:06.35 DEBUG: |   = note: the following crate versions were found:
 0:06.35 DEBUG: |           crate `std` compiled by rustc 1.29.2: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-9f1d9aae8b99d108.rlib
 0:06.35 DEBUG: |           crate `std` compiled by rustc 1.31.1: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-57b3410c37ed439b.rlib
 0:06.35 DEBUG: |           crate `std` compiled by rustc 1.31.1: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-57b3410c37ed439b.so
 0:06.35 DEBUG: |           crate `std` compiled by rustc 1.29.2: /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-160f1a26cff4fc58.rlib

And from firefox-build-dir/config.log:

INFO: checking cargo version... 
DEBUG: Executing: `/usr/bin/cargo --version --verbose`
INFO: 1.32.0
DEBUG: Executing: `/usr/bin/rustc --print target-list`
DEBUG: Creating `/tmp/conftestxYkoWQ.rs` with content:
DEBUG: | pub extern fn hello() { println!("Hello world"); }
DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib --target=x86_64-unknown-linux-gnu -o /tmp/conftesthJIO24.rlib /tmp/conftestxYkoWQ.rs`
DEBUG: The command returned non-zero exit status 1.
DEBUG: Its error output was:
DEBUG: | error[E0464]: multiple matching crates for `std`

Google finds E0514 where people altered their code to fix test failures and had to recompile stage0. For E0464, no matches for the std crate.

Looks as if the target list is ok (all known target triplets), so the 'hello world' test within firefox's attempt to understand the installed rust is the problem. Possibly the static lib crate type.

Not sure where I'm going now, I think I might have broken the system (in particular, blowing away /usr/lib/rustlib will probably prevent me using the runnimg firefox if I have to reboot).

comment:7 by ken@…, 3 years ago

System *is* broken. I tried recompiling librsvg because that is the lightest user of rust. Similar errors for crates core and std.

The odd thing is that my logs show 1.32.0 completed its installation. Clearly something in my "use shipped llvm" build is incorrect.

IOn the end, I blew away /usr/lib/rustlib as well as /usr/bin/cargo* /usr/bin/clippy* /usr/bin/rls /usr/bin/rust* and /usr/share/doc/rustc* : but I still need to think about what is wrong with the latest build (and drop ARM).

Meanwhile, I've reinstalled 1.31.1. For future experiments with 1.32.0 I'll go back to installing in /opt (as well as getting it working, I want to look at the number of codegen units - with thinlto there is a compromise between rust's build time and space.

For reference, the issue with system LLVM on Arch is https://github.com/rust-lang/rust/issues/57762

comment:8 by ken@…, 3 years ago

Not looking good with 1.32.0. I had hoped to use thin-lto to save time and space. That turns out to need LLVM's lld linker (which is a separate download like cfe/clang). But after building that, it seems that it will only use *static* system libraries.

Gave up on that, trying a regular X86 build with shipped LLVM but it fails to load the stage1 codegen lib librustc_codegen_llvm-llvm.so with the message

LLVM-8svn.so: cannot open shared object file: No such file or directory

comment:9 by Douglas R. Reno, 3 years ago

Any idea why rust wants a development version of LLVM? That seems sort of fishy to me.

Why don't we just use 1.31.1 and hold off on 1.32.0?

comment:10 by Bruce Dubbs, 3 years ago

Just another data point. I built ructc-1.32.0 on my development system (12 core Haswell, 16G RAM). It seemed to almost finish and then:

error: failed to run custom build command for `miri v0.1.0 (/mnt/tmp/rustc/rustc-1.32.0-src/src/tools/miri)`
process didn't exit successfully: `/mnt/tmp/rustc/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2-tools/release/build/miri-7bdefdbab42072df/build-script-build` (exit code: 101)
--- stdout
cargo:rustc-env=PROFILE=release
cargo:rerun-if-changed=build.rs
cargo:rustc-env=VERGEN_BUILD_TIMESTAMP=2019-01-21T07:58:35.074019866+00:00
cargo:rustc-env=VERGEN_SHA=
cargo:rustc-env=VERGEN_BUILD_DATE=2019-01-21
cargo:rustc-env=VERGEN_SEMVER_LIGHTWEIGHT=0.1.0
cargo:rustc-env=VERGEN_SHA_SHORT=
cargo:rustc-env=VERGEN_SEMVER=0.1.0
cargo:rustc-env=VERGEN_TARGET_TRIPLE=x86_64-unknown-linux-gnu
cargo:rustc-env=VERGEN_COMMIT_DATE=
--- stderr
thread 'main' panicked at 'Unable to generate vergen keys!: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

warning: build failed, waiting for other jobs to finish...
error: build failed                                                                     
command did not execute successfully: "/mnt/tmp/rustc/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "12" "--release" "--manifest-path" "/mnt/tmp/rustc/rustc-1.32.0-src/src/tools/miri/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
Build completed successfully in 0:21:44

This seems to match the caveat in the book.

I do have the following:

./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ./build/x86_64-unknown-linux-gnu/stage2/bin/rustc ./build/x86_64-unknown-linux-gnu/stage0/bin/rustc

I was able to run the stage2 version with

$ export LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage2/lib
$ ./build/x86_64-unknown-linux-gnu/stage2/bin/rustc --version
rustc 1.32.0

A ran the build manually with the instructions in the book so I do not have a log or timing. The directory size after build is 3.6G. I'm stopping now, and I have not run any tests yet. I have not run the install either. I'll try those tomorrow.

comment:11 by Bruce Dubbs, 3 years ago

I did find this: https://github.com/rust-lang/rust/issues/56576

They closed the issue, but it does not seem to be fixed.

comment:12 by Pierre Labastie, 3 years ago

what about this patch? I'll give it a try.

comment:13 by Pierre Labastie, 3 years ago

miri built OK with the patch. Build completed in about 20 SBU with 4 cores. 3.6 GB in source tree. +300 MB in user home.

comment:14 by Pierre Labastie, 3 years ago

I've run the tests (using instructions in the book). 15795 tests were run and 22 failed...

comment:15 by Pierre Labastie, 3 years ago

I've run a DESTDIR install (book instructions). With tests and install the size of the build tree is 7.5 GB, the size of the "install" dir is 716 MB. I do not have accurate timings for the last two operations, sorry.

So, seems to work on intel. Remains to find what to do with Ryzen...

comment:16 by Pierre Labastie, 3 years ago

Both cbindgen and librsvg could be compiled with the above build. I did not have a previous version of rust on this VM, so it might be that I only have the "good" crates.

comment:17 by Bruce Dubbs, 3 years ago

When I did my test build last night, I did not adjust my ~/.cargo directory, Right now I have

[ ~ ]$ du -sh .cargo 747M .cargo

So it appears that the build procedure can handle old cargo files.

comment:18 by Pierre Labastie, 3 years ago

Tried to compile firefox-65.0, from firefox-65.0b12.source.tar.xz.

Using book instructions, with harfbuzz/graphite2 patch. The patch does not apply cleanly and I applied it manually.

After ~23 mn (with 4 cores), I get:

22:17.78   process didn't exit successfully: `/usr/bin/rustc --crate-name gkrust
 toolkit/library/rust/lib.rs --color never --crate-type staticlib --emit=dep-inf
o,link -C opt-level=2 -C panic=abort -C codegen-units=1 -C lto --cfg 'feature="b
indgen"' --cfg 'feature="cubeb-remoting"' --cfg 'feature="cubeb_pulse_rust"' --c
fg 'feature="gecko_profiler"' --cfg 'feature="gkrust-shared"' --cfg 'feature="mo
z_memory"' --cfg 'feature="quantum_render"' --cfg 'feature="servo"' -C metadata=
c80ab26d4d3f38e1 -C extra-filename=-c80ab26d4d3f38e1 --out-dir /sources/firefox-
65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps --target x86_64-unk
nown-linux-gnu -C linker=/sources/firefox-65.0/build/cargo-linker -L dependency=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps -L dependency=/sources/firefox-65.0/firefox-build-dir/release/deps --extern gkrust_shared=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps/libgkrust_shared-a27c3e3102207894.rlib --extern mozilla_central_workspace_hack=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps/libmozilla_central_workspace_hack-cb43fdc5b1f7b177.rlib -C opt-level=2 -C debuginfo=2 -L native=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/build/lmdb-sys-2deb7105a462014f/out` (signal: 11, SIGSEGV: invalid memory reference)
22:17.78 make[4]: *** [/sources/firefox-65.0/config/rules.mk:1052: force-cargo-library-build] Error 101

Well, SIGSEGV: invalid memory reference can come from the fact I use a VM...

in reply to:  9 comment:19 by ken@…, 3 years ago

Replying to renodr:

Any idea why rust wants a development version of LLVM? That seems sort of fishy to me.

Why don't we just use 1.31.1 and hold off on 1.32.0?

No idea why they require a development version, except that clearly they do. Note that on *some* machines 1.32.0 works fine, and for those the test results are much cleaner.

comment:20 by Douglas R. Reno, 3 years ago

Morning folks.

rustc-1.32.0 on an i5-6600k:

   Compiling vergen v3.0.3                                                                                                                   
   Compiling miri v0.1.0 (/sources/rustc-1.32.0-src/src/tools/miri)                                                                          
error: failed to run custom build command for `miri v0.1.0 (/sources/rustc-1.32.0-src/src/tools/miri)`                                       
process didn't exit successfully: `/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2-tools/release/build/miri-7bdefdbab42072df/build-script-build` (exit code: 101)
--- stdout
cargo:rustc-env=PROFILE=release
cargo:rerun-if-changed=build.rs
cargo:rustc-env=VERGEN_BUILD_TIMESTAMP=2019-01-21T14:07:31.816889152+00:00
cargo:rustc-env=VERGEN_SEMVER_LIGHTWEIGHT=0.1.0
cargo:rustc-env=VERGEN_SHA=
cargo:rustc-env=VERGEN_COMMIT_DATE=
cargo:rustc-env=VERGEN_SEMVER=0.1.0
cargo:rustc-env=VERGEN_TARGET_TRIPLE=x86_64-unknown-linux-gnu
cargo:rustc-env=VERGEN_SHA_SHORT=
cargo:rustc-env=VERGEN_BUILD_DATE=2019-01-21

--- stderr
thread 'main' panicked at 'Unable to generate vergen keys!: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

command did not execute successfully: "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "x86_64-unknown-linux-gnu" "-j" "4" "--release" "--manifest-path" "/sources/rustc-1.32.0-src/src/tools/miri/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
Build completed successfully in 0:30:10

If I wasn't busy working on the i686 box, I'd run it over there just for laughs. I'm having issues with it and Firefox/Thunderbird, so I'm going to just run a different web browser and email client. For some odd reason, rust won't link in swap space.

in reply to:  14 ; comment:21 by ken@…, 3 years ago

Replying to pierre.labastie:

I've run the tests (using instructions in the book). 15795 tests were run and 22 failed...

For 1.32.0 with only X86 enabled, you should get 4 failures (three for tests which require thumb (ARM) compilers, one for a cargo test). Having 22 failures matches my segfaults.

in reply to:  18 comment:22 by ken@…, 3 years ago

Replying to pierre.labastie:

Tried to compile firefox-65.0, from firefox-65.0b12.source.tar.xz.

Using book instructions, with harfbuzz/graphite2 patch. The patch does not apply cleanly and I applied it manually.

Version at http://www.linuxfromscratch.org/~ken/dev-patches/ hopefully applies cleanly.

After ~23 mn (with 4 cores), I get:

22:17.78   process didn't exit successfully: `/usr/bin/rustc --crate-name gkrust
 toolkit/library/rust/lib.rs --color never --crate-type staticlib --emit=dep-inf
o,link -C opt-level=2 -C panic=abort -C codegen-units=1 -C lto --cfg 'feature="b
indgen"' --cfg 'feature="cubeb-remoting"' --cfg 'feature="cubeb_pulse_rust"' --c
fg 'feature="gecko_profiler"' --cfg 'feature="gkrust-shared"' --cfg 'feature="mo
z_memory"' --cfg 'feature="quantum_render"' --cfg 'feature="servo"' -C metadata=
c80ab26d4d3f38e1 -C extra-filename=-c80ab26d4d3f38e1 --out-dir /sources/firefox-
65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps --target x86_64-unk
nown-linux-gnu -C linker=/sources/firefox-65.0/build/cargo-linker -L dependency=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps -L dependency=/sources/firefox-65.0/firefox-build-dir/release/deps --extern gkrust_shared=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps/libgkrust_shared-a27c3e3102207894.rlib --extern mozilla_central_workspace_hack=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/deps/libmozilla_central_workspace_hack-cb43fdc5b1f7b177.rlib -C opt-level=2 -C debuginfo=2 -L native=/sources/firefox-65.0/firefox-build-dir/x86_64-unknown-linux-gnu/release/build/lmdb-sys-2deb7105a462014f/out` (signal: 11, SIGSEGV: invalid memory reference)
22:17.78 make[4]: *** [/sources/firefox-65.0/config/rules.mk:1052: force-cargo-library-build] Error 101

Well, SIGSEGV: invalid memory reference can come from the fact I use a VM...

Yeah, gkrust is where the problem shows up.

in reply to:  20 comment:23 by ken@…, 3 years ago

Replying to renodr:

Morning folks.

rustc-1.32.0 on an i5-6600k:

   Compiling vergen v3.0.3                                                                                                                   
   Compiling miri v0.1.0 (/sources/rustc-1.32.0-src/src/tools/miri)                                                                          

[...]

Build completed successfully in 0:30:10

Code 101 is not, in itself, fatal. The rust build system is nasty (builds which are marked as unsuccessful return a good status, allowing the tests, and then the install code, to each run for a time), but if it thinks it was successful then maybe it completed.

My expectation is that most problems will be on AMD (a comment on -book in reply to this ticket about a phenom having problems).

in reply to:  21 ; comment:24 by Pierre Labastie, 3 years ago

Replying to ken@…:

Replying to pierre.labastie:

I've run the tests (using instructions in the book). 15795 tests were run and 22 failed...

For 1.32.0 with only X86 enabled, you should get 4 failures (three for tests which require thumb (ARM) compilers, one for a cargo test). Having 22 failures matches my segfaults.

Actually, I had only run the statistics as explained in the book. I see now that some tests have failed on signal 11 (SIGSEGV). So the SIGSEGV in firefox is not unexpected...

in reply to:  17 comment:25 by ken@…, 3 years ago

Replying to bdubbs:

When I did my test build last night, I did not adjust my ~/.cargo directory, Right now I have

[ ~ ]$ du -sh .cargo 747M .cargo

So it appears that the build procedure can handle old cargo files.

They just build up - if the old versions are not used, they are merely taking space. 'The rust way' seems to be to use specific versions in each crate, so that three different versions can be used when building rust itself. If none are present, the required ones get downloaded.

in reply to:  24 comment:26 by ken@…, 3 years ago

Replying to pierre.labastie:

Replying to ken@…:

Actually, I had only run the statistics as explained in the book. I see now that some tests have failed on signal 11 (SIGSEGV). So the SIGSEGV in firefox is not unexpected...

Thanks, this is why a development version of LLVM is needed (or perhaps a patched version).

I might take another attempt at trying to build with the shipped LLVM tomorrow, but for the moment I think that 1.31.0 is the way to go.

comment:27 by ken@…, 3 years ago

PROGRESS ;-)

I've used the shipped llvm, got only 3 test failures, successfully compiled latest librsvg [ that is now my goto "does it seem to work" test ]. Still need to test-build beta and current stable firefoxes, cbindgen and thunderbird, and do other tests / measurements. The big difference is that I've put it in /opt/new. I've also disabled the docs (man pages seem to be present).

The build and DESTDIR install took 34 SBU, tests took only 15 SBU (for 1.31.1 with system llvm the figures were 28 SBU and 24 SBU). Space is MUCH smaller because of omitting the docs (5.7GB including the DESTDIR which adds 476MB when installed, i.e. 6.1GB total, tests add 2GB.

config.toml:

# see config.toml.example for more possible options             
[llvm]

# use ninja 
ninja = true 

# by default, rust will build for a myriad of architectures
targets = "X86"
# When building llvm, WebAssembly and RISCV experimental
# targets are the default. omit those  
experimental-targets = ""

[build]
# do not build and install the docs
docs = false

# install cargo as well as rust
extended = true

[install]
prefix = "/opt/new"
# keep a docdir for people who build the docs     
docdir = "share/doc/rustc-1.32.0" 

[rust]
channel = "stable"
rpath = false

# BLFS does not install the FileCheck executable from llvm,
# so disable codegen tests
codegen-tests = false

backtrace-on-ice = true

Logs (build, test, with summary added at end, install) at http://www.linuxfromscratch.org/~ken/logs/ (for the moment, I'll delete them at some point) - they probably show that I was building in /scratch/ken/crap - that is just a place for throwaway builds as a user, it is not a comment on what I am building.

comment:28 by ken@…, 3 years ago

Release notes at https://github.com/rust-lang/rust/blob/master/RELEASES.md

Note that both the earlier 1.31.0 and the current 1.32.0 are described as the '2018 edition'.

comment:29 by ken@…, 3 years ago

Successfully test-built the books's current versions of firefox, thunderbird, librsvg, cbindgen. Build firefox-65beta12. Ran the gdb tests (I have not kept earlier results, but the rust items looked similar or perhaps better).

Installed "for real" in /usr. Looking good, I'm now running firefox-65.0 (candidate 1).

comment:30 by Douglas R. Reno, 3 years ago

Hey Ken, do you want me to look into that Phenom thing, and update the ticket with results from my machine? That will tell us whether or not we're looking at a fluke on gab's end or if there's a problem with Athlon/Phenom systems. It'll probably be 24-36 hours, depending on overall speed of my Phenom.

in reply to:  30 comment:31 by ken@…, 3 years ago

Replying to renodr:

Hey Ken, do you want me to look into that Phenom thing, and update the ticket with results from my machine? That will tell us whether or not we're looking at a fluke on gab's end or if there's a problem with Athlon/Phenom systems. It'll probably be 24-36 hours, depending on overall speed of my Phenom.

That is overtaken by events: upstream rust has now established that LLVM-7.0.1 is NOT good enough (errors on various crates).

However, I'm currently swearing and cursing - on my phenom where I had updated to 1.32.0 with system LLVM and things appeared to be ok, I "updated" to 1.32.0 with shipped LLVM. I'm back to rust only finding crates compiled by old versions (in this case 1.25.0 and 1.29.0). That seems to now be a feature of compiling 1.32.0 with system LLVM and then replacing it with a version using the shipped LLVM.

On my haswell which previously was running 1.29.2 the upgrade was fine, so this only seems to happen if upgrading from the same version with system LLVM.

comment:32 by Douglas R. Reno, 3 years ago

On my Skylake with *shipped* LLVM, I'm having some serious issues with the tests... they abort!

  - "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage0-tools-bin/compiletest" "--compile-lib-path" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/lib" "--run-lib-path" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib" "--rustc-path" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "--rustdoc-path" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustdoc" "--src-base" "/sources/rustc-1.32.0-src/src/test/run-make-fulldeps" "--build-base" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-make-fulldeps" "--stage-id" "stage2-x86_64-unknown-linux-gnu" "--mode" "run-make" "--target" "x86_64-unknown-linux-gnu" "--host" "x86_64-unknown-linux-gnu" "--llvm-filecheck" "/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--nodejs" "/usr/bin/node" "--host-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--target-rustcflags" "-Crpath -O -Zunstable-options  -Lnative=/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/native/rust-test-helpers" "--docck-python" "/usr/bin/python" "--lldb-python" "/usr/bin/python" "--gdb" "/usr/bin/gdb" "--verbose" "--quiet" "--llvm-version" "8.0.0svn\n" "--cc" "cc" "--cxx" "c++" "--cflags" "-ffunction-sections -fdata-sections -fPIC -m64" "--llvm-components" "aggressiveinstcombine all all-targets analysis asmparser asmprinter binaryformat bitreader bitwriter codegen core coroutines coverage debuginfocodeview debuginfodwarf debuginfomsf debuginfopdb demangle dlltooldriver engine executionengine fuzzmutate globalisel gtest gtest_main instcombine instrumentation interpreter ipo irreader libdriver lineeditor linker lto mc mcdisassembler mcjit mcparser mirparser native nativecodegen objcarcopts object objectyaml option optremarks orcjit passes profiledata runtimedyld scalaropts selectiondag support symbolize tablegen target testingsupport transformutils vectorize windowsmanifest x86 x86asmparser x86asmprinter x86codegen x86desc x86disassembler x86info x86utils xray" "--llvm-cxxflags" "-I/sources/rustc-1.32.0-src/src/llvm/include -I/sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/llvm/build/include -ffunction-sections -fdata-sections -fPIC -m64 -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-class-memaccess -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG  -fno-exceptions -fno-rtti -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS" "--ar" "ar" "--adb-path" "adb" "--adb-test-dir" "/data/tmp/work" "--android-cross-path" ""

Traceback (most recent call last):
  File "./x.py", line 20, in <module>
    bootstrap.main()
  File "/sources/rustc-1.32.0-src/src/bootstrap/bootstrap.py", line 853, in main
    bootstrap(help_triggered)
  File "/sources/rustc-1.32.0-src/src/bootstrap/bootstrap.py", line 839, in bootstrap
    run(args, env=env, verbose=build.verbose)
  File "/sources/rustc-1.32.0-src/src/bootstrap/bootstrap.py", line 151, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /sources/rustc-1.32.0-src/build/bootstrap/debug/bootstrap test --verbose --no-fail-fast

This is what I have now, although the tests aborted:

renodr [ /sources/rustc-1.32.0-src ]$ grep '^test result:' rustc-testlog | awk  
'{ sum += $6 } END { print sum }'                                               
4                                                                               
renodr [ /sources/rustc-1.32.0-src ]$ grep 'running .* tests' rustc-testlog | awk '{ sum += $2 } END { print sum }'                                             
15795

This is a big improvement over *system* LLVM though:

renodr [ /sources/rustc-1.32.0-src.sysllvm ]$ grep 'running .* tests' rustc-testlog | awk '{ sum += $2 } END { print sum }'                                     
15795                                                                           
renodr [ /sources/rustc-1.32.0-src.sysllvm ]$ grep '^test result:' rustc-testlog | awk  '{ sum += $6 } END { print sum }'                                       
20

in reply to:  32 ; comment:33 by ken@…, 3 years ago

Replying to renodr:

On my Skylake with *shipped* LLVM, I'm having some serious issues with the tests... they abort!

Getting a traceback is normal (one or more tests failed). 4 failures is probably ok. If you look for FAIL in the log, I will guess that the last one is sysroot-crates-are-unstable in run-make ?

This is a big improvement over *system* LLVM though:

I assume you discarded that log. If not, or in your systemd journal, I assume there are many segfaults (two, and a number of traps for invalid opcodes, are normal).

comment:34 by Douglas R. Reno, 3 years ago

There are a lot less segfaults for the *shipped* LLVM, but there are still several:

Wed 2019-01-23 20:18:27 CST   21007  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:18:48 CST   31981  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/abort-on-c-abi/a
Wed 2019-01-23 20:19:20 CST    3685  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/backtrace/a
Wed 2019-01-23 20:19:20 CST    3631  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/backtrace/a
Wed 2019-01-23 20:19:24 CST   10423  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/default-alloc-error-hook/a
Wed 2019-01-23 20:19:58 CST   18673  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/invalid_const_promotion/a
Wed 2019-01-23 20:20:20 CST   24468  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/issues/issue-24313/a
Wed 2019-01-23 20:20:22 CST   10263  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:20:33 CST   13786  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:21:18 CST    8997  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/out-of-stack/a
Wed 2019-01-23 20:21:22 CST    9039  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/out-of-stack/a
Wed 2019-01-23 20:21:24 CST   10749  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/abort/a
Wed 2019-01-23 20:21:27 CST   10780  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/abort-link-to-unwinding-crates/a
Wed 2019-01-23 20:21:54 CST   20991  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/running-with-no-runtime/a
Wed 2019-01-23 20:21:56 CST   21272  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/segfault-no-out-of-stack/a
Wed 2019-01-23 20:22:02 CST   22793  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/signal-exit-status/a
Wed 2019-01-23 20:22:03 CST   24721  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/simd/simd-target-feature-mixup/a
Wed 2019-01-23 20:22:13 CST     917  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:22:13 CST   25388  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes/a
Wed 2019-01-23 20:22:39 CST     974  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:23:24 CST   10796  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:23:35 CST   10737  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:23:37 CST   22319  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:23:56 CST   25171  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:25:12 CST   13804  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:25:34 CST   16712  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:40:17 CST   26664  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:40:25 CST   26989  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:40:38 CST   28960  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:40:49 CST   30324  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:40:49 CST   30458  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:40:50 CST   30465  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:40:51 CST   30321  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:40:52 CST   31085  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:44:36 CST    4798  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:44:39 CST    4850  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:44:43 CST    5350  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:44:49 CST    4787  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:44:51 CST    4788  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:44:54 CST    4753  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:44:56 CST    4906  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:44:57 CST    4789  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:45:05 CST    4916  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:45:15 CST    6794  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:45:15 CST    4851  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:50:47 CST    8485  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:50:48 CST    8296  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:50:51 CST    8444  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:50:52 CST    8363  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:50:55 CST    8437  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:50:57 CST    8476  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:50:59 CST    8334  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:50:59 CST    8534  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:51:45 CST   10793  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:52:42 CST   10730  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:52:43 CST   10765  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:52:47 CST   10883  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:52:49 CST   10767  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:52:53 CST   10831  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:52:59 CST   10893  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:53:02 CST   10766  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:53:06 CST   12810  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:57:20 CST   13054  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:57:22 CST   13119  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:57:22 CST   13193  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:57:22 CST   13241  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:57:22 CST   13232  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:57:23 CST   13290  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:57:23 CST   13198  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 20:57:23 CST   13083  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/stage2/bin/rustc
Wed 2019-01-23 23:20:43 CST   23460  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/abort-on-c-abi/a
Wed 2019-01-23 23:21:13 CST   27121  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/backtrace/a
Wed 2019-01-23 23:21:14 CST   27164  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/backtrace/a
Wed 2019-01-23 23:21:16 CST    1844  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/default-alloc-error-hook/a
Wed 2019-01-23 23:21:41 CST   10054  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/invalid_const_promotion/a
Wed 2019-01-23 23:21:56 CST   15939  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/issues/issue-24313/a
Wed 2019-01-23 23:22:43 CST    2472  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/out-of-stack/a
Wed 2019-01-23 23:22:45 CST    2831  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/out-of-stack/a
Wed 2019-01-23 23:22:47 CST    5663  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/abort/a
Wed 2019-01-23 23:22:47 CST    5653  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/abort-link-to-unwinding-crates/a
Wed 2019-01-23 23:22:50 CST    8358  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/panic-runtime/lto-abort/a
Wed 2019-01-23 23:23:04 CST   14766  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/running-with-no-runtime/a
Wed 2019-01-23 23:23:05 CST   14788  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/segfault-no-out-of-stack/a
Wed 2019-01-23 23:23:07 CST   15792  1000  1000  11 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/signal-exit-status/a
Wed 2019-01-23 23:23:09 CST   16211  1000  1000   4 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/simd/simd-target-feature-mixup/a
Wed 2019-01-23 23:23:11 CST   16878  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes/a
Wed 2019-01-23 23:23:14 CST   17753  1000  1000   6 present   /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes-lto/a

With *system* LLVM, I have close to 275 coredumps.

As for the difference in time, I forgot to use Bruce's sed and it failed while I was asleep.

As for invalid opcodes:

[987171.293783] traps: a[23460] trap invalid opcode ip:557dfccb3b3b sp:7fff1a7ad0a0 error:0 in a[557dfccb2000+3000]
[987181.162671] traps: a[27121] trap invalid opcode ip:7fbd9c4a6abf sp:7ffea4ea5920 error:0 in libstd-be3f5b84c0422bf0.so[7fbd9c49c000+71000]
[987181.405544] traps: a[27164] trap invalid opcode ip:7fc20d3deabf sp:7ffce6318600 error:0 in libstd-be3f5b84c0422bf0.so[7fc20d3d4000+71000]
[987230.071842] traps: a[10054] trap invalid opcode ip:557cfdfad5d1 sp:7ffef27d8d90 error:0 in a[557cfdfac000+2000]

[987313.464168] a[14788]: segfault at 0 ip 00005591671569b8 sp 00007ffe13d70600 error 6 in a[559167155000+2000]
[987313.464174] Code: 00 00 48 8b b4 24 00 01 00 00 48 85 f6 74 1e 48 8b bc 24 f8 00 00 00 ba 01 00 00 00 ff 15 88 35 00 00 eb 09 ff 15 d8 35 00 00 <c6> 00 01 48 8b 84 24 50 01 00 00 48 c1 e0 03 48 8d 1c 40 31 ed 4c
[987316.148033] a[15792]: segfault at 1 ip 000055dff4cfc57e sp 00007ffe19aa3b90 error 6 in a[55dff4cfb000+2000]
[987316.148039] Code: 48 85 c0 74 16 48 c1 e0 03 48 8d 34 40 ba 08 00 00 00 4c 89 ff ff 15 e9 29 00 00 48 81 c4 a8 01 00 00 5b 41 5c 41 5e 41 5f c3 <48> c7 04 25 01 00 00 00 00 00 00 00 eb 90 48 8d 3d 0d 27 00 00 31
[987317.945057] traps: a[16211] trap invalid opcode ip:5635add9cb0f sp:7ffe802b88d0 error:0 in a[5635add9b000+4000]

in reply to:  33 ; comment:35 by ken@…, 3 years ago

Replying to ken@…:

Replying to renodr:

On my Skylake with *shipped* LLVM, I'm having some serious issues with the tests... they abort!

Getting a traceback is normal (one or more tests failed). 4 failures is probably ok. If you look for FAIL in the log, I will guess that the last one is sysroot-crates-are-unstable in run-make ?

This is a big improvement over *system* LLVM though:

I assume you discarded that log. If not, or in your systemd journal, I assume there are many segfaults (two, and a number of traps for invalid opcodes, are normal).

My totals (with only 3 failed tests are 15687 passed, 108 ignored (if gdb is present), or 15605 and 190 if gdb is not available. The totals are about 3 greater than the claimed number of tests.

For miri I am now using

export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" &&
./x.py build --exclude src/tools/miri

You added your traces and segfaults while I was writing that, can you look at the latest log and search for segfault / sigsegv / signal 11 to find out if any were reported in the output.

in reply to:  35 comment:36 by Douglas R. Reno, 3 years ago

Replying to ken@…:

Replying to ken@…:

Replying to renodr:

On my Skylake with *shipped* LLVM, I'm having some serious issues with the tests... they abort!

Getting a traceback is normal (one or more tests failed). 4 failures is probably ok. If you look for FAIL in the log, I will guess that the last one is sysroot-crates-are-unstable in run-make ?

This is a big improvement over *system* LLVM though:

I assume you discarded that log. If not, or in your systemd journal, I assume there are many segfaults (two, and a number of traps for invalid opcodes, are normal).

My totals (with only 3 failed tests are 15687 passed, 108 ignored (if gdb is present), or 15605 and 190 if gdb is not available. The totals are about 3 greater than the claimed number of tests.

With GDB installed, I get 15795 total tests, 4 "failures", and 108 ignored.

For miri I am now using

export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" &&
./x.py build --exclude src/tools/miri

You added your traces and segfaults while I was writing that, can you look at the latest log and search for segfault / sigsegv / signal 11 to find out if any were reported in the output.

It doesn't seem that any are reported, at least via a simple grep. I can upload my rustc-testlog to my webspace if that'll help at all.

As an example of one of my coredumps (seems to be a SIGABRT):

           PID: 17753 (a)
           UID: 1000 (renodr)
           GID: 1000 (renodr)
        Signal: 6 (ABRT)
     Timestamp: Wed 2019-01-23 23:23:14 CST (11h ago)
  Command Line: /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes-lto/a child-thread
    Executable: /sources/rustc-1.32.0-src/build/x86_64-unknown-linux-gnu/test/run-pass/stack-probes-lto/a
 Control Group: /system.slice/sshd.service
          Unit: sshd.service
         Slice: system.slice
       Boot ID: b14abce378314253b307b60837c5de6f
    Machine ID: 7777b247b5d14d1d980532e847b5461b
      Hostname: POOH
       Storage: /var/lib/systemd/coredump/core.a.1000.b14abce378314253b307b60837c5de6f.17753.1548307394000000.xz
       Message: Process 17753 (a) of user 1000 dumped core.

comment:37 by ken@…, 3 years ago

First set of changes in r21033 - updated now to help reduce the confusion when people test it. Details of failures might need tweaking if more come to light.

I've also put down a marker in the changelog that it will be moving to /opt, but that the instructions for using it should be in a form where an existing install in /usr can be used.

That will be a time to document the problems a bit more, and maybe to advise using a different prefix if rebuilding with major changes in config.toml (e.g. shipped llvm vs system llvm).

comment:38 by Bruce Dubbs, 3 years ago

Just a progress report. I tried to change the value of prefix in config.toml to /opt/rust or /opt/rustc-1.32.0, but it won't work. I've developed a workaround.

After DESTDIR=${PWD}/install ./x.py install:

mkdir -p install/opt/rustc-1.32.0
mv install/usr/* install/opt/rustc-1.32.0
rmdir install/usr

and then continue with

chown -R root:root install
cp -a install/* /   

And finish with

ln -sfnv rustc-1.32.0 /opt/rustc


For ld.so.conf, add '/opt/rustc/lib' and run ldconfig.

Add a boot script that does 'pathprepend /opt/rustc/bin'

Seems to work. I'll create a new branch and change the book there for review.

comment:39 by Bruce Dubbs, 3 years ago

comment:40 by Bruce Dubbs, 3 years ago

Using input from Ken, I've simplified the proposed rust page:

http://www.linuxfromscratch.org/~bdubbs/blfs-book/general/rust.html

This is the same location as the previous comment.

comment:41 by Bruce Dubbs, 3 years ago

I've updated the book with (optional) instructions to build rustc in /opt. There may still be some changes needed so I'm leaving this ticket open for Ken to review what is now in the book, make any changes needed, and then finally close this ticket.

We have been trying to get this working properly for quite a while. I do not know if we want to update llvm-7.0.1 with Arch's patch and try rebuilding rust with system llvm. Maybe that should wait until the next rust version.

comment:42 by ken@…, 3 years ago

Owner: changed from ken@… to Bruce Dubbs
Status: assignednew

I think we should make the wording for /opt stronger, whilst still allowing people to use /usr, and spell out why. Also, use ln -svfn for the symlink instead of first removing /opt/rustc (I was not aware of that option until Bruce pointed it out to me, I think it has educational benefit). And explain that people should use a different prefix if rebuilding.

Although I said I wasn't going to mention the problem re reinstalling the same version after changing from system llvm to shipped llvm, I changed my mind now we are using /opt, and spelled it out so that future readers can see why we changed.

Committed at r21044, passing to Bruce to alter if he thinks I've overdone it, or to close.

comment:43 by Bruce Dubbs, 3 years ago

Resolution: fixed
Status: newclosed

This is close enough. If changes are needed, reopen or create a new ticket.

Note: See TracTickets for help on using tickets.