rustc segfaults on small program using rayon

[larswirzenius]

Code

The attached tarball has two versions of my program, reduced as much as I can. In the build subdirectory the program works fine. In fails building it causes a segfault. In both, build command was cargo build. This is entirely reproducible for me.

rustc-bug.tar.gz

Meta

rustc --version --verbose:

rustc 1.51.0 (2fd73fabe 2021-03-23)
binary: rustc
commit-hash: 2fd73fabe469357a12c2c974c140f67e7cdd76d0
commit-date: 2021-03-23
host: x86_64-unknown-linux-gnu
release: 1.51.0
LLVM version: 11.0.1

Error output

10:25 exolobe1:~/tmp/rustc-bug $ cd builds/
10:25 exolobe1:~/.../builds $ cargo build -q
10:25 exolobe1:~/.../builds $ cd ../fails/
10:26 exolobe1:~/.../fails $ cargo build -q
warning: field is never read: `data`
  --> src/main.rs:24:5
   |
24 |     data: [u8; SIZE],
   |     ^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

error: could not compile `checksum-concurrency`

Caused by:
  process didn't exit successfully: `rustc --crate-name checksum_concurrency --edition=2018 src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=bb6d00e4307bf22c -C extra-filename=-bb6d00e4307bf22c --out-dir /home/liw/tmp/rustc-bug/fails/target/debug/deps -C incremental=/home/liw/tmp/rustc-bug/fails/target/debug/incremental -L dependency=/home/liw/tmp/rustc-bug/fails/target/debug/deps --extern rayon=/home/liw/tmp/rustc-bug/fails/target/debug/deps/librayon-875aabede64e7eb2.rlib --extern sha2=/home/liw/tmp/rustc-bug/fails/target/debug/deps/libsha2-eb3b7d824c3f1ca0.rlib` (signal: 11, SIGSEGV: invalid memory reference)
[PREVIOUS COMMAND EXIT: 101]
10:48 exolobe1:~/.../fails $ 

Backtrace

``` No backtrace.

[smmalis37]

If I did this right, the backtrace I'm getting says this is happening inside llvm during codegen:

[0x0]   rustc_driver_35567a90ab3243c7!llvm::SelectionDAG::ReplaceAllUsesWith + 0x171   
[0x1]   rustc_driver_35567a90ab3243c7!llvm::SmallVectorImpl<llvm::IntervalMapImpl::NodeRef>::swap + 0x49a5   
[0x2]   rustc_driver_35567a90ab3243c7!llvm::EVT::bitsEq + 0x1dc6   
[0x3]   rustc_driver_35567a90ab3243c7!llvm::TargetLowering::DAGCombinerInfo::CommitTargetLoweringOpt + 0x8550   
[0x4]   rustc_driver_35567a90ab3243c7!llvm::SelectionDAG::Combine + 0x34   
[0x5]   rustc_driver_35567a90ab3243c7!llvm::SelectionDAGISel::CodeGenAndEmitDAG + 0xee   
[0x6]   rustc_driver_35567a90ab3243c7!llvm::SelectionDAGISel::SelectAllBasicBlocks + 0x1393   
[0x7]   rustc_driver_35567a90ab3243c7!llvm::SelectionDAGISel::runOnMachineFunction + 0x5ce   
[0x8]   rustc_driver_35567a90ab3243c7!llvm::SmallVectorImpl<std::pair<llvm::SDValue,llvm::SDNode * __ptr64> >::resize + 0x104   
[0x9]   rustc_driver_35567a90ab3243c7!llvm::MachineFunctionPass::runOnFunction + 0x1d4   
[0xa]   rustc_driver_35567a90ab3243c7!llvm::FPPassManager::runOnFunction + 0x288   
[0xb]   rustc_driver_35567a90ab3243c7!llvm::FPPassManager::runOnModule + 0x43   
[0xc]   rustc_driver_35567a90ab3243c7!llvm::FPPassManager::runOnModule + 0x287   
[0xd]   rustc_driver_35567a90ab3243c7!llvm::legacy::PassManager::run + 0xb0   
[0xe]   rustc_driver_35567a90ab3243c7!LLVMRustWriteOutputFile + 0x353   
[0xf]   rustc_driver_35567a90ab3243c7!rustc_codegen_llvm::back::write::write_output_file + 0xe3   
[0x10]   rustc_driver_35567a90ab3243c7!rustc_codegen_llvm::back::write::codegen::{{closure}} + 0x3a   
[0x11]   rustc_driver_35567a90ab3243c7!rustc_codegen_llvm::back::write::codegen::with_codegen<closure-2,core::result::Result<tuple<>, rustc_span::fatal_error::FatalError>> + 0x84   
[0x12]   rustc_driver_35567a90ab3243c7!rustc_codegen_llvm::back::write::codegen + 0xdcd   
[0x13]   rustc_driver_35567a90ab3243c7!rustc_codegen_llvm::{{impl}}::codegen + 0x4a   
[0x14]   rustc_driver_35567a90ab3243c7!rustc_codegen_ssa::back::write::finish_intra_module_work<rustc_codegen_llvm::LlvmCodegenBackend> + 0xf9   
[0x15]   rustc_driver_35567a90ab3243c7!rustc_codegen_ssa::back::write::execute_optimize_work_item + 0x4d3   
[0x16]   rustc_driver_35567a90ab3243c7!rustc_codegen_ssa::back::write::execute_work_item<rustc_codegen_llvm::LlvmCodegenBackend> + 0x891   
[0x17]   rustc_driver_35567a90ab3243c7!rustc_codegen_ssa::back::write::spawn_work::{{closure}} + 0xb0   
[0x18]   rustc_driver_35567a90ab3243c7!std::sys_common::backtrace::__rust_begin_short_backtrace<closure-0,tuple<>> + 0xdf   
[0x19]   rustc_driver_35567a90ab3243c7!std::thread::{{impl}}::spawn_unchecked::{{closure}}::{{closure}} + 0x1c   
[0x1a]   rustc_driver_35567a90ab3243c7!std::panic::{{impl}}::call_once + 0x1c   
[0x1b]   rustc_driver_35567a90ab3243c7!std::panicking::try::do_call + 0x20   
[0x1c]   rustc_driver_35567a90ab3243c7!std::panicking::try<tuple<>,std::panic::AssertUnwindSafe<closure-0>> + 0x3e   
[0x1d]   rustc_driver_35567a90ab3243c7!std::panic::catch_unwind + 0x2b   
[0x1e]   rustc_driver_35567a90ab3243c7!std::thread::{{impl}}::spawn_unchecked::{{closure}} + 0xf9   
[0x1f]   rustc_driver_35567a90ab3243c7!core::ops::function::FnOnce::call_once<closure-0,tuple<>> + 0x12b   
[0x20]   std_590731d75ecdff17!alloc::boxed::{{impl}}::call_once + 0xe   
[0x21]   std_590731d75ecdff17!alloc::boxed::{{impl}}::call_once<tuple<>,alloc::boxed::Box<FnOnce<tuple<>>, alloc::alloc::Global>,alloc::alloc::Global> + 0x2b   
[0x22]   std_590731d75ecdff17!std::sys::windows::thread::{{impl}}::new::thread_start + 0x23   
[0x23]   KERNEL32!BaseThreadInitThunk + 0x14   
[0x24]   ntdll!RtlUserThreadStart + 0x21

[cuviper]

I can reproduce this on x86_64-unknown-linux-gnu with 1.52.0-beta.3 and 1.53.0-nightly (d0695c908 2021-04-12), so we can at least say that LLVM 12 hasn't fixed the underlying issue.

Also, downgrading to rayon 1.0.3 builds successfully, but with rayon 1.1.0 it hits the same compiler crash.

[tmiasko]

pub unsafe fn f(p: *const [u8; 128 * 1024]) {
    p.read_volatile();
}

rustc: ../llvm-project/llvm/include/llvm/CodeGen/SelectionDAGNodes.h:1062: llvm::SDNode::SDNode(unsigned int, unsigned int, llvm::DebugLoc, llvm::SDVTList): Assertion `NumValues == VTs.NumVTs && "NumValues wasn't wide enough for its operands!"' failed.
Aborted

[langston-barrett]

Potentially related to #94793 per @tmiasko's comment.

[RodBurman]

Using the current stable toolchain:

% cargo -v -V
cargo 1.85.1 (d73d2caf9 2024-12-31)
release: 1.85.1
commit-hash: d73d2caf9e41a39daf2a8d6ce60ec80bf354d2a7
commit-date: 2024-12-31
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.7.1 (sys:0.4.74+curl-8.9.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 15.3.2 [64-bit]

The "fails" code now builds, with a single warning:

 % cargo build
    Updating crates.io index
     Locking 16 packages to latest compatible versions
      Adding sha2 v0.9.9 (available: v0.10.8)
   Compiling typenum v1.18.0
   Compiling version_check v0.9.5
   Compiling crossbeam-utils v0.8.21
   Compiling libc v0.2.171
   Compiling rayon-core v1.12.1
   Compiling cfg-if v1.0.0
   Compiling either v1.15.0
   Compiling opaque-debug v0.3.1
   Compiling generic-array v0.14.7
   Compiling cpufeatures v0.2.17
   Compiling crossbeam-epoch v0.9.18
   Compiling crossbeam-deque v0.8.6
   Compiling block-buffer v0.9.0
   Compiling digest v0.9.0
   Compiling sha2 v0.9.9
   Compiling rayon v1.10.0
   Compiling checksum-concurrency v0.1.0 (/Users/rod/code/rust/triage/rcsegf/fails)
warning: field `data` is never read
  --> src/main.rs:24:5
   |
23 | struct Blob {
   |        ---- field in this struct
24 |     data: [u8; SIZE],
   |     ^^^^
   |
   = note: `#[warn(dead_code)]` on by default

warning: `checksum-concurrency` (bin "checksum-concurrency") generated 1 warning
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.02s

So I think this issue can be closed, though it maybe that changes in the crate dependencies have obscured a still existing problem in rustic, but I am not sure how we could tell without reproduction code.