rustc 1.64.0 crashes on riscv64gc-unknown-linux-gnu

[lunasophia]

I upgraded my stable-riscv64gc-unknown-linux-gnu Rust toolchain on my StarFive VisionFive board running the official Ubuntu release this afternoon. I then tried to use the compiler, but I receive a reproducible compiler error. I can confirm that version 1.63.0 works without issue.

Code

I tried this code:

fn main() {
}

I expected to see this happen: the code to build

Instead, this happened: I receive a reproducible error (see backtrace below).

Version it worked on

It most recently worked on: Rust 1.63

Version with regression

rustc --version --verbose:

rustc 1.64.0 (a55dd71d5 2022-09-19)
binary: rustc
commit-hash: a55dd71d5fb0ec5a6a3a9e8c27b2127ba491ce52
commit-date: 2022-09-19
host: riscv64gc-unknown-linux-gnu
release: 1.64.0
LLVM version: 14.0.6

Backtrace

Backtrace

$ RUST_BACKTRACE=1 cargo run
   Compiling foo v0.1.0 (/home/luna/foo)
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc3d810)[0x3f8d079810]
linux-vdso.so.1(__vdso_rt_sigreturn+0x0)[0x3f93b0f800]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0x3cea1aa)[0x3f901261aa]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(_RNvCsZJaBwVYvUP_16rustc_query_impl15query_callbacks+0x916c)[0x3f9032cbaa]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0x94700a)[0x3f8cd8300a]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xd57d14)[0x3f8d193d14]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xcce018)[0x3f8d10a018]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xcccb48)[0x3f8d108b48]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(_RNvMs0_NtCs2PGdSkTarcu_15rustc_interface7queriesNtB5_7Queries11global_ctxt+0x300)[0x3f8d182794]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xbecada)[0x3f8d028ada]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc387a6)[0x3f8d0747a6]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xbed8d4)[0x3f8d0298d4]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc0a996)[0x3f8d046996]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc04666)[0x3f8d040666]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc06da4)[0x3f8d042da4]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/librustc_driver-ac972a4e10c98556.so(+0xc0b6da)[0x3f8d0476da]
/home/luna/.rustup/toolchains/stable-riscv64gc-unknown-linux-gnu/bin/../lib/libstd-f41102d4d21d2c30.so(rust_metadata_std_ac92b06979af539e+0xa0542)[0x3f8c38e542]
/lib/riscv64-linux-gnu/libc.so.6(+0x675a6)[0x3f8c21e5a6]
error: could not compile `foo`

Caused by:
  process didn't exit successfully: `rustc --crate-name foo --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=1b3b0ae194b7a453 -C extra-filename=-1b3b0ae194b7a453 --out-dir /home/luna/foo/target/debug/deps -C incremental=/home/luna/foo/target/debug/incremental -L dependency=/home/luna/foo/target/debug/deps` (signal: 11, SIGSEGV: invalid memory reference)
$

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[apiraino]

WG-prioritization assigning P-critical for the moment (Zulip discussion).

Would be great if someone could identify where this regression started (also using cargo bisect).

@lunasophia just curious, did you have a chance to try nightlies or betas between the two stable 1.63 and 1.64? The answer might be there somewhere. Thanks.

@rustbot label -I-prioritize +P-critical E-needs-bisection

[lunasophia]

@lunasophia just curious, did you have a chance to try nightlies or betas between the two stable 1.63 and 1.64? The answer might be there somewhere. Thanks.

I have not, but I'll look at writing a script to automate it over the weekend.

[lunasophia]

While testing this (i.e. I specified the date range for my search incorrectly and pulled in a post-1.64.0 nightly), I noticed the nightly I just installed does work without issue:

cargo 1.66.0-nightly (73ba3f35e 2022-09-18)
release: 1.66.0-nightly
commit-hash: 73ba3f35e0205844418260722c11602113179c4a
commit-date: 2022-09-18
host: riscv64gc-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.83.1-DEV (sys:0.4.55+curl-7.83.1 vendored ssl:OpenSSL/1.1.1q)
os: Ubuntu 22.04 (jammy) [64-bit]

If further bisecting is desired, I'd be happy to do so, though I'm a little unclear on how nightly dates match up to version numbers. I installed the 2022-08-11 nightly (expecting it to be 1.64 or 1.63), and it's 1.65 (and still broken), so a list of dates to try would help me narrow down my search.

[lunasophia]

I joined the Zulip chat and ran cargo-bisect-rustc as instructed. After some trial and error with the date range I found the following:

searched nightlies: from nightly-2022-05-30 to nightly-2022-08-01
regressed nightly: nightly-2022-07-18
searched commit range: d5e7f47...263edd4
regressed commit: 263edd4

bisected with cargo-bisect-rustc v0.6.4

Host triple: riscv64gc-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc 2022-05-30 --end 2022-08-01 --test-dir .

[Rageking8]

Maybe cc @5225225 ?

[5225225]

Wait what?

That code shouldn't take effect unless you're running with -Zstrict-init-checks. And even then, it should be a panic, not an abort.

Very strange! Maybe try running gdb or valgrind on the binary and then seeing where the segfault is?