Skip to content

Illegal hardware instruction #80002

New issue

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

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

Already on GitHub? # to your account

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 <aramisnoah@gmail.com>"]
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

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

No branches or pull requests

3 participants