Open astral4 opened 7 months ago
Seems that miri thinks the loop9
crate itself has unsoundness. Simply doing:
loop9::Triple::new(1u8, 2, 3).as_ref();
Produces:
error: Undefined Behavior: trying to retag from <1689> for SharedReadOnly permission at alloc828[0x1], but that tag does not exist in the borrow stack for this location
--> /home/jonathan/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/raw.rs:102:9
|
102 | &*ptr::slice_from_raw_parts(data, len)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| |
| trying to retag from <1689> for SharedReadOnly permission at alloc828[0x1], but that tag does not exist in the borrow stack for this location
| this error occurs as part of retag at alloc828[0x0..0x3]
|
= help: this indicates a potential bug in the program: it performed an invalid operation, but the Stacked Borrows rules it violated are still experimental
= help: see https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md for further information
help: <1689> was created by a SharedReadOnly retag at offsets [0x0..0x1]
--> src/main.rs:2:5
|
2 | / loop9::Triple::new(1u8, 2, 3)
3 | | .as_ref();
| |_________________^
= note: BACKTRACE (of the first span):
= note: inside `std::slice::from_raw_parts::<'_, u8>` at /home/jonathan/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/raw.rs:102:9: 102:47
= note: inside `<loop9::Triple<u8> as std::convert::AsRef<[u8]>>::as_ref` at /home/jonathan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/loop9-0.1.4/src/lib.rs:25:13: 25:54
note: inside `main`
--> src/main.rs:2:5
|
2 | / loop9::Triple::new(1u8, 2, 3)
3 | | .as_ref();
| |_________________^
note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace
However, there doesn't seem to be a git repository linked from the crate page to create an issue against.
@kornelski, since you're listed as the crate owner, could you take a look?
I've updated the crate. It didn't like me using address of the first field as the address of the struct. So I don't think there's any actual problem there, since the two pointers are numerically the same, it takes miri to spot the difference.
I updated the repository reproducing this issue to use loop9
0.1.5, but I still get zsh: illegal hardware instruction
. (I also replaced the test image to speed up Miri runs.) Miri still reports UB, but now it is in the crossbeam-epoch
crate. The output of cargo +nightly miri run
is:
This error doesn't happen with -Zmiri-disable-stacked-borrows
or -Zmiri-tree-borrows
. Instead, Miri errors upon encountering this foreign function in the rav1e
crate, since Miri doesn't support calling it.
This happens with version 0.24.8. I am using a M1 MacBook Pro with
rustc 1.75.0 (82e1608df 2023-12-21)
.Running the program that brings up this issue results in
zsh: illegal hardware instruction
.Miri output
The output of
cargo +nightly miri run
(usingrustc 1.77.0-nightly (2319be8e2 2024-01-12)
) is:Reproduction steps
cargo run --release
I only observed UB on release builds with
panic = "abort"
andlto = true
, but Miri still reports UB otherwise.