STATUS_ACCESS_VIOLATION in cranelift-codegen build script

[novacrazy]

When attempting to add cranelift to a project of mine for use as a JIT compiler, I get:

error: failed to run custom build command for `cranelift-codegen v0.38.0`

Caused by:
  process didn't exit successfully: `F:\code\projects\active\untitled\target\debug\build\cranelift-codegen-c6b973378c2b1052\build-script-build` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)
--- stdout
cargo:rerun-if-changed=C:\Users\novacrazy\.cargo\registry\src\github.com-1ecc6299db9ec823\cranelift-codegen-0.38.0\build.rs

warning: build failed, waiting for other jobs to finish...
error: build failed

This seems to be caused by my build configuration in Cargo.toml:

[profile.dev]
debug = true
opt-level = 2
incremental = false
debug-assertions = true
codegen-units = 32

[profile.release]
opt-level = 3
debug = true # helps with profiling
lto = 'fat'
incremental = false
debug-assertions = false
codegen-units = 1

[profile.bench]
opt-level = 3
debug = false
lto = 'fat'
debug-assertions = false
incremental = false
codegen-units = 1

which upon adding to the SimpleJIT demo config causes the same STATUS_ACCESS_VIOLATION

I'm on Windows 10 Pro for Workstations with a AMD Zen 1 Threadripper 1950X, compiling with RUSTFLAGS = "-C target-cpu=native", so znver1.

Compiling without target-cpu=native seems to work, but I kind of use that...

So it's a mix of those config options and target-cpu=native.

I'm using rustc 1.38.0-nightly (60960a260 2019-08-12), which is after an LLVM update known to cause issues on Zen 1

[novacrazy]

No, just tested it on an older version before that LLVM update, and the STATUS_ACCESS_VIOLATION still occurs, so it's not LLVM.

[sunfishcode]

This is the first report of such a problem, so I don't know what might be causing it.

Are you able to run the build-script-build program in a debugger? It needs the TARGET environment variable set to your target triple, possibly "x86_64-pc-windows-msvc", and OUT_DIR set to the path of an empty directory. It would be interesting if we could determine where it's failing.

[novacrazy]

To be honest all I have to debug it is Visual Studio, and I'm not well versed on how to use that with Rust.

Given the stdout in the build error message, though, it seems to fail at this piece of code:

if let Err(err) = meta::generate(&isas, &out_dir) {
    eprintln!("Error: {}", err);
    process::exit(1);
}

so it got past the environment variable checks.

[novacrazy]

I've narrowed it down to this chunk of code in cranelift\cranelift-codegen\meta\src\shared\legalize.rs

for cc in &["eq", "ne", "ugt", "ult", "uge", "ule"] {
    let w_cc = Literal::enumerator_for(intcc, cc);
    widen.legalize(
        def!(a = icmp_imm.int_ty(w_cc, b, c)),
        vec![def!(x = uextend.I32(b)), def!(a = icmp_imm(w_cc, x, c))],
    );
    widen.legalize(
        def!(a = icmp.int_ty(w_cc, b, c)),
        vec![
            def!(x = uextend.I32(b)),
            def!(y = uextend.I32(c)),
            def!(a = icmp.I32(w_cc, x, y)),
        ],
    );
}

[bnjbvr]

Looks like a rustc compiler bug. Does it reproduce when using Rustc stable? Does it reproduce in all of your profiles with Rustc nightly?

If you add print statements to this code to print what the cc code causing this is, does it still reproduce, and if so, what's the output?

[novacrazy]

It does still occur on stable rustc 1.37.0.

By adding some printlns to that code, I found the error occurs inside the first call to widen.legalize, not in the generation of the parameters.

[novacrazy]

Huh. Oddly enough, this is the exact same code that is in https://github.com/CraneStation/cranelift/issues/896

[bnjbvr]

ping @novacrazy, does it still happen with latest Rustc, out of curiosity?

[bjorn3]

#63959 is still open. And a comment from yesterday there says that it is still reproducable.

[bnjbvr]

rust-lang/rust#63959 (comment) is solved and hopefully in the current Rust nightly.

@novacrazy Can you try again please with the latest Rust nightly, and let us know if this is fixed? Thanks!

[novacrazy]

I haven’t had time to check recently, but I will soon. JIT compilation is still very much on my radar.

Given the details of the aforementioned LLVM bug, it makes sense that the error happened unexpectedly within a loop, so hopefully it will be fixed now.

[novacrazy]

I think this has been fixed by that LLVM patch. It's extremely odd that it was still failing before the LLVM 9 upgrade back in August, but oh well. The SimpleJIT example compiles and runs fine now.