You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using the allocator_api feature of this crate and nightly, I noticed that Miri does not like this:
#![feature(allocator_api)]fnmain(){let bump = bumpalo::Bump::new();let a = Box::into_raw(Box::new_in(1u8,&bump));drop(unsafe{Box::from_raw_in(a,&bump)});let _b = Box::new_in(2u16,&bump);}
Miri error:
error: Undefined Behavior: trying to retag from <2737> for SharedReadWrite permission at alloc1066[0x1be], but that tag does not exist in the borrow stack for this location
--> C:\...\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\alloc\src\boxed.rs:385:13
|
385 | boxed.as_mut_ptr().write(x);
| ^^^^^
| |
| trying to retag from <2737> for SharedReadWrite permission at alloc1066[0x1be], but that tag does not exist in the borrow stack for this location
| this error occurs as part of two-phase retag at alloc1066[0x1be..0x1c0]
|
= 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: <2737> was created by a SharedReadWrite retag at offsets [0x1bf..0x1c0]
--> src/main.rs:6:13
|
6 | let a = Box::into_raw(Box::new_in(1u8, &bump));
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: BACKTRACE (of the first span):
= note: inside `std::boxed::Box::<u16, &bumpalo::Bump>::new_in` at C:\...\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\alloc\src\boxed.rs:385:13: 385:18
note: inside `main`
--> src/main.rs:9:14
|
9 | let _b = Box::new_in(2u16, &bump);
| ^^^^^^^^^^^^^^^^^^^^^^^^
The exact types of the allocations involved does not matter much, only that _b allocates something with an alignment larger than a.
I'm pretty new to Miri, so I'm not quite sure what the issue is exactly. It seems like the combination of the retagging in Box::into_raw, the deallocation in of the recreated box, and the layout differences are the essential parts. This is not triggered if the Box is dropped without the pointer roundtrip, nor with bumpalo::boxed::Box, nor when using bump.reset() instead of drop. It does show up when using allocator-api2 and its Box.
The text was updated successfully, but these errors were encountered:
bluurryy
added a commit
to bluurryy/bumpalo
that referenced
this issue
May 19, 2024
Hi, thank you for the great work!
Using the
allocator_api
feature of this crate and nightly, I noticed that Miri does not like this:Miri error:
The exact types of the allocations involved does not matter much, only that
_b
allocates something with an alignment larger thana
.I'm pretty new to Miri, so I'm not quite sure what the issue is exactly. It seems like the combination of the retagging in
Box::into_raw
, the deallocation in of the recreated box, and the layout differences are the essential parts. This is not triggered if theBox
is dropped without the pointer roundtrip, nor withbumpalo::boxed::Box
, nor when usingbump.reset()
instead ofdrop
. It does show up when usingallocator-api2
and itsBox
.The text was updated successfully, but these errors were encountered: