Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Illegal hardware instruction #80002

Closed
lunacookies opened this issue Dec 13, 2020 · 2 comments
Closed

Illegal hardware instruction #80002

lunacookies opened this issue Dec 13, 2020 · 2 comments
Labels
C-bug Category: This is a bug.

Comments

@lunacookies
Copy link
Contributor

lunacookies commented Dec 13, 2020

I was helping a friend on Advent of Code Day 13 Part 2, and ran this broken (as in doesn’t solve the problem and accidentally loops forever) code:

fn main() {
    let data = (
        1015292,
        &[
            19, 0, 0, 0, 0, 0, 0, 0, 0, 41, 0, 0, 0, 0, 0, 0, 0, 0, 0, 743, 0, 0, 0, 0, 0, 0, 0, 0,
            0, 0, 0, 0, 13, 17, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 29, 0, 643, 0, 0, 0, 0,
            0, 37, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 23,
        ][..],
    );

    println!("{}", find_earliest_timestamp(data));
}

fn find_earliest_timestamp(data: (usize, &[usize])) -> usize {
    let mut timestamp = 0;
    let mut valid = false;

    while !valid {
        let valid = true;
        let mut i = 0;

        while i < data.1.len() {
            if data.1[i] != 0 && (timestamp + i) % data.1[i] != 0 {
                let valid = false;
                break;
            }

            i += 1;
        }

        timestamp += data.1[0];
    }

    timestamp
}

Cargo.toml:

[package]
name = "thing"
version = "0.1.0"
authors = ["Aramis Razzaghipour <[email protected]>"]
edition = "2018"
$ rustc --version --verbose
rustc 1.48.0 (7eac88abb 2020-11-16)
binary: rustc
commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
commit-date: 2020-11-16
host: x86_64-apple-darwin
release: 1.48.0
LLVM version: 11.0

Running with cargo run does the right thing and loops forever (since valid is never mutated to be true). Running with cargo run --release gives an ‘illegal hardware instruction’ error:

$ cargo run --release
   Compiling thing v0.1.0 (/home/me/thing)
warning: unused variable: `valid`
  --> src/main.rs:19:13
   |
19 |         let valid = true;
   |             ^^^^^ help: if this is intentional, prefix it with an underscore: `_valid`
   |
   = note: `#[warn(unused_variables)]` on by default

warning: unused variable: `valid`
  --> src/main.rs:24:21
   |
24 |                 let valid = false;
   |                     ^^^^^ help: if this is intentional, prefix it with an underscore: `_valid`

warning: variable does not need to be mutable
  --> src/main.rs:16:9
   |
16 |     let mut valid = false;
   |         ----^^^^^
   |         |
   |         help: remove this `mut`
   |
   = note: `#[warn(unused_mut)]` on by default

warning: 3 warnings emitted

    Finished release [optimized] target(s) in 0.89s
     Running `target/release/thing`
zsh: illegal hardware instruction  cargo run --release

This happens both when compiling incrementally and when compiling from scratch.

I repeatedly removed more and more elements from the code until I ended up with the following minimal example (it might not function the same, but it still gives the same error):

fn main() {
    a();
}

fn a() {
    loop {
        loop {}
    }
}

Curiously the ‘illegal hardware instruction’ error goes away if I manually inline a() into main(). Adding #[inline(always)] to a() does not remove the error, though.

Compiling with nightly

$ rustc --version --verbose
rustc 1.50.0-nightly (7efc097c4 2020-12-12)
binary: rustc
commit-hash: 7efc097c4fe6e97f54a44cee91c56189e9ddb41c
commit-date: 2020-12-12
host: x86_64-apple-darwin
release: 1.50.0-nightly

or beta

$ rustc --version --verbose
rustc 1.49.0-beta.4 (877c7cbe1 2020-12-10)
binary: rustc
commit-hash: 877c7cbe142a373f93d38a23741dcc3a0a17a2af
commit-date: 2020-12-10
host: x86_64-apple-darwin
release: 1.49.0-beta.4

fixes the issue.

@lunacookies lunacookies added the C-bug Category: This is a bug. label Dec 13, 2020
@SNCPlay42
Copy link
Contributor

This is probably #28728.

@jonas-schievink
Copy link
Contributor

Yup

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

3 participants