STATUS_ACCESS_VIOLATION happens frequently with rust 1.83 under windows x64 environment

[maple19out]

I tried this code:

<code>
fn main() {
    println!("hihi");
}

I expected to see this happen:
Just a normal "hihi" string printed out on my console

Instead, this happened: explanation

PS C:\Users\maple\Desktop\etc\dev\temp> cargo run
   Compiling temp v0.1.0 (C:\Users\maple\Desktop\etc\dev\temp)
error: could not compile `temp` (bin "temp")

Caused by:
  process didn't exit successfully: `C:\Users\maple\.rustup\toolchains\1.83-x86_64-pc-windows-msvc\bin\rustc.exe --crate-name temp --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=142 --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --check-cfg cfg(docsrs) --check-cfg "cfg(feature, values())" -C metadata=d54b924dfe4288ad --out-dir C:\Users\maple\Desktop\etc\dev\temp\target\debug\deps -C incremental=C:\Users\maple\Desktop\etc\dev\temp\target\debug\incremental -L dependency=C:\Users\maple\Desktop\etc\dev\temp\target\debug\deps` (exit code: 0xc0000005, STATUS_ACCESS_VIOLATION)

Meta

rustc --version --verbose:

<version>
PS C:\Users\maple\Desktop\etc\dev\temp> rustc --version --verbose
rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-pc-windows-msvc
release: 1.83.0
LLVM version: 19.1.1

Backtrace

Hi, I used rust 1.81 before and upgraded to 1.83 today. When I write any codes and execute through 'cargo run' command, error happens frequently and randomly. I tried this on wsl, but it was fine.

I guess there might be some bug with recently rust compiler (version 1.83) under windows / x86_64 environment

[ChrisDenton]

I guess there might be some bug with recently rust compiler (version 1.83) under windows / x86_64 environment

Given that the code is trivial I think that is unlikely. We test in CI and 1.83 was released on 28 November, yet this is the first report.

I guess it is possible this is a result of an incremental bug, in which case cargo clean may help. But given that it happens intermittently it may point to some problem in the environment. E.g. anti-malware software or faulty hardware.

[jieyouxu]

I can't repro this locally on native x86_64-pc-windows-msvc.

[jieyouxu]

@maple19out if you go back to 1.81.0, and do a compile binary -> run binary multiple times -> remove output artifacts (e.g. in a loop), does it also segfault? Does it also segfault consistently like this in a loop with 1.83.0? How about nightly, or beta?

[Noratrieb]

could you run memtest86? might be a hardware issue

[maple19out]

well I'm not sure whether it matters, i'll provide detailed context for the error.

1. i upgraded from version 1.81 to 1.83,
2. i tried to compile & execute rust code below - just for learning rust features

code

// src/smart_pointer_application/main.rs
use std::io::{stdin, stdout, Write};

fn get_user_input() -> String {
    let mut s = String::new();
    let _ = stdout().flush();
    stdin()
        .read_line(&mut s)
        .expect("Did not enter a correct string");
    if let Some('\n') = s.chars().next_back() {
        s.pop();
    }
    if let Some('\r') = s.chars().next_back() {
        s.pop();
    }
    s
}

trait GenSerialData {
    fn get_input(&mut self);
    fn generate(&self) -> Option<&str>;
}

struct UserID {
    digit: u32,
    id: Option<String>,
}

impl GenSerialData for UserID {
    fn get_input(&mut self) {
        println!("Please input {}-digits User ID: ", self.digit);
        self.id = Some(get_user_input());
    }

    fn generate(&self) -> Option<&str> {
        self.id.as_ref().map(|x| x.as_str())
    }
}

struct ProductID {
    digit: u32,
    id: Option<String>,
}

impl GenSerialData for ProductID {
    fn get_input(&mut self) {
        println!("Please input {}-digits Product ID: ", self.digit);
        self.id = Some(get_user_input());
    }

    fn generate(&self) -> Option<&str> {
        self.id.as_ref().map(|x| x.as_str())
    }
}

//fn collect_data(items: &mut Vec<Box<dyn GenSerialData>>) { // If you want to use Vec<Box<dyn GenSerialData>> in main function
fn collect_data(items: &mut [Box<dyn GenSerialData>]) {
    for item in items.iter_mut() {
        item.get_input();
    }
}

// &[&dyn GenSerialData] is wrong!
//fn generate_serial(items: &Vec<Box<dyn GenSerialData>>) -> String { // If you want to use Vec<Box<dyn GenSerialData>> in main function
fn generate_serial(items: &[Box<dyn GenSerialData>]) -> String {
    let mut data = String::new();
    for item in items.iter() {
        data.push_str(item.generate().unwrap());
    }
    data
}

fn main() {
    println!("hello");

    let userid = UserID { digit: 4, id: None };
    let productid = ProductID { digit: 8, id: None };

    // Vec<&dyn GenSerialData> is wrong!
    //let mut items: Vec<Box<dyn GenSerialData>> = vec![Box::new(userid), Box::new(productid)];
    let mut items = [Box::new(userid), Box::new(productid)];

    collect_data(&mut items);
    let serial = generate_serial(&items);
    println!("Serial generated: {}", serial);
}

and I got compile error below,

compile error log

error[E0308]: mismatched types
  --> src/main.rs:83:34
   |
83 |     let serial = generate_serial(&items);
   |                  --------------- ^^^^^^ expected `&[Box<dyn GenSerialData>]`, found `&[Box<UserID>; 2]`
   |                  |
   |                  arguments to this function are incorrect
   |
   = note: expected reference `&[Box<(dyn GenSerialData + 'static)>]`
              found reference `&[Box<UserID>; 2]`

3. I was curious why rust infers items variable as &[Box<UserID>;2], not as &[Box<(dyn GenSerialData)>] from the code below

let mut items = [Box::new(userid), Box::new(productid)]; // automatic, but wrong inference

      so I changed the order of elements of items array as below

let mut items = [Box::new(productid), Box::new(userid)]; 

and I started to get STATUS_ACCESS_VIOLATION...
I tried to figure out root cause of the problem, but still doesn't know why 😂
I'm currently using Windows OS 11 / x86_64 arch / rust 1.83 stable version

@ChrisDenton I tried cargo clean & cargo build, power off & on my computer, making a new crate with cargo new, but still randomly having the same problem, but I also couldn't reproduce it on another windows machine. May be the error is dependent to my computer.

@jieyouxu I tested various rust versions and results are

rust version	result
1.83 stable (recent version)	STATUS_ACCESS_VIOLATION
1.84 beta	STATUS_ACCESS_VIOLATION
1.85 nightly	STATUS_ACCESS_VIOLATION
1.81 stable	(compiles well)
but segfault is continuosly occuring with only one machine

@Noratrieb I couldn't run memtest86 right now, but I don't expect hardware flaw on the machine... I'll try out later

Thanks for the comments. I'm quite suspicious with my pc environment right now...
I'll update the issue if it was related to rust internals

[workingjubilee]

@maple19out You may wish to review other issues we've root-caused to defective hardware. In particular, it is useful to keep in mind a CPU that performs acceptably at other applications may fail when executing a stress-test that pushes the hardware to its limits. The Rust compiler is exactly such a stress test, and the performance characteristics of the compiler change between versions in ways that can serve as an inflection point.

https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aclosed%20label%3AC-defective-hardware