Panic in nightly 1.83.0 and 1.84.0 with opt-level >= 1 when unwrapping Some variant

When calling an unwrap on a value that should be Some, i instead get an unwrap on None error. Attaching a debugger seems to show an invalid memory error.

This issue happens only when opt-level is set to at least 1, (aka in dev profile, no panic happens, and in release it does), and only happens in rust nightly 1.83.0 and 1.84.0, it does not happen on stable and nightly 1.82.0.

~~I'm not sure if the issue is in my code or in the sprs crate, i've filed an issue there and also here just to make sure.~~
EDIT: managed to narrow down the bug by removing the sprs crate, this is only pure rust

Here is the repo for minimum example or in the playground, there is an even smaller reproduction in the comments

To reproduce, run cargo run --release which will panic, while if running cargo run it won't panic

I've tried to run this with miri, nothing there. Also tried to run the release mode with bounds checking turned on, but nothing changed

Meta

rustc --version --verbose:

rustc 1.84.0-nightly (3f1be1ec7 2024-10-28)
binary: rustc
commit-hash: 3f1be1ec7ec3d8e80beb381ee82164a0aa3ca777
commit-date: 2024-10-28
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.1

Backtrace

thread 'main' panicked at src/main.rs:122:27:
called `Option::unwrap()` on a `None` value
stack backtrace:
   0: rust_begin_unwind
             at /rustc/3f1be1ec7ec3d8e80beb381ee82164a0aa3ca777/library/std/src/panicking.rs:665:5
   1: core::panicking::panic_fmt
             at /rustc/3f1be1ec7ec3d8e80beb381ee82164a0aa3ca777/library/core/src/panicking.rs:75:14
   2: core::panicking::panic
             at /rustc/3f1be1ec7ec3d8e80beb381ee82164a0aa3ca777/library/core/src/panicking.rs:152:5
   3: core::option::unwrap_failed
             at /rustc/3f1be1ec7ec3d8e80beb381ee82164a0aa3ca777/library/core/src/option.rs:2008:5
   4: microlp::order_simple
   5: microlp::main
             at ./src/main.rs:152:5
   6: core::ops::function::FnOnce::call_once
             at /home/specy/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250:5

@dianqk

cargo-bisect-rustc suggest that regression is in e7386b3 (cc @dianqk)

Minimized:

fn pop_min(mut score2head: Vec<Option<usize>>) -> Option<usize> {
    loop {
        if let Some(col) = score2head[0] {
            score2head[0] = None;
            return Some(col);
        }
    }
}

fn main() {
    let min = pop_min(vec![Some(1)]);
    println!("min: {:?}", min);
    // panic happens here on beta in release mode
    min.unwrap();
}

Working on a revert for e7386b3, we can reland that mir-opt with this fixed.

@rustbot

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical

about the corpus, the rust repo and all its history are around 25 gb of code already, seems like a good start :)

for i in `git rev-list --objects --all  | grep "\.rs"   | cut -d' ' -f1` ; do ; git cat-file -p $i > ${i}.rs ; done

This is now a discussion of how to fuzz rustc, which is much better had elsewhere.

I believe that @cbeuw did that kind of fuzzing, but I don't think its still running?

His dissertation https://dl.acm.org/doi/pdf/10.1145/3689780 says it took 10 CPU-years of fuzzing to uncover 22 new bugs. That's low enough yield that this needs to run on a server somewhere, not in someone's dev environment (much less a shared dev environment).

Infra may be willing to help run it, but someone would need to do the work to maintain the codebase.

Sadly, for mir-opt bugs like this, the best defense we have is still to be really extra super careful when writing and reviewing them. Fuzzing and other tooling can catch some bugs, but not nearly enough.

Infra may be willing to help run it, but someone would need to do the work to maintain the codebase.

More importantly, someone needs to sift through the reports generated by the tool, and turn them into useful bug reports.

Auto merge of rust-lang#132527 - DianQK:gvn-stmt-iter, r=<try>

kani is not what I want. I'm writing an alive2-like tool for MIR, but I can't guarantee when it will be completed.

Auto merge of rust-lang#132527 - DianQK:gvn-stmt-iter, r=oli-obk

Auto merge of rust-lang#132527 - DianQK:gvn-stmt-iter, r=<try>

Auto merge of rust-lang#132527 - DianQK:gvn-stmt-iter, r=oli-obk

Navigation Menu

Repository navigation

Panic in nightly 1.83.0 and 1.84.0 with opt-level >= 1 when unwrapping Some variant #132353

Meta

32 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Panic in nightly 1.83.0 and 1.84.0 with opt-level >= 1 when unwrapping Some variant #132353

Description

Meta

Activity

theemathas commented on Oct 30, 2024

tmiasko commented on Oct 30, 2024

theemathas commented on Oct 30, 2024

jieyouxu commented on Oct 30, 2024

apiraino commented on Oct 30, 2024

32 remaining items

matthiaskrgr commented on Nov 19, 2024

saethlin commented on Nov 19, 2024

RalfJung commented on Nov 22, 2024

dianqk commented on Dec 19, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions