Auto merge of #2145 - saethlin:zero-size-creation, r=RalfJung
Save a created event for zero-size reborrows Currently, we don't save a created event for zero-sized reborrows. Attempting to use something from a zero-sized reborrow is surprisingly common, for example on `minimal-lexical==0.2.1` we previously just emit this: ``` Undefined Behavior: attempting a write access using <187021> at alloc72933[0x0], but that tag does not exist in the borrow stack for this location --> /root/rust/library/core/src/ptr/mod.rs:1287:9 | 1287 | copy_nonoverlapping(&src as *const T, dst, 1); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | | | attempting a write access using <187021> at alloc72933[0x0], but that tag does not exist in the borrow stack for this location | this error occurs as part of an access at alloc72933[0x0..0x8] | = help: this indicates a potential bug in the program: it performed an invalid operation, but the 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 = note: inside `std::ptr::write::<u64>` at /root/rust/library/core/src/ptr/mod.rs:1287:9 note: inside `minimal_lexical::stackvec::StackVec::push_unchecked` at /root/build/src/stackvec.rs:82:13 --> /root/build/src/stackvec.rs:82:13 | 82 | ptr::write(self.as_mut_ptr().add(self.len()), value); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... backtrace continues... ``` Which leaves us with the question "where did we make this pointer?" because for every other diagnostic you get a "was created by" note, so I suspect people might be tempted to think there is a Miri bug here. I certainly was. --- This code duplication is so awful, I'm going to take a look at cleaning it up later. The fact that `ptr_get_alloc_id` can fail in this situation makes things annoying.
This commit is contained in:
commit
aa589d3dc7
@ -706,7 +706,26 @@ fn reborrow(
|
||||
) -> InterpResult<'tcx> {
|
||||
let this = self.eval_context_mut();
|
||||
if size == Size::ZERO {
|
||||
// Nothing to do for zero-sized accesses.
|
||||
// Don't update any stacks for a zero-sized access; borrow stacks are per-byte and this
|
||||
// touches no bytes so there is no stack to put this tag in.
|
||||
// However, if the pointer for this operation points at a real allocation we still
|
||||
// record where it was created so that we can issue a helpful diagnostic if there is an
|
||||
// attempt to use it for a non-zero-sized access.
|
||||
// Dangling slices are a common case here; it's valid to get their length but with raw
|
||||
// pointer tagging for example all calls to get_unchecked on them are invalid.
|
||||
if let Ok((alloc_id, base_offset, orig_tag)) = this.ptr_try_get_alloc_id(place.ptr) {
|
||||
let extra = this.get_alloc_extra(alloc_id)?;
|
||||
let stacked_borrows =
|
||||
extra.stacked_borrows.as_ref().expect("we should have Stacked Borrows data");
|
||||
let mut alloc_history = stacked_borrows.history.borrow_mut();
|
||||
alloc_history.log_creation(
|
||||
Some(orig_tag),
|
||||
new_tag,
|
||||
alloc_range(base_offset, Size::ZERO),
|
||||
&mut this.machine.current_span(),
|
||||
);
|
||||
}
|
||||
|
||||
trace!(
|
||||
"reborrow of size 0: {} reference {:?} derived from {:?} (pointee {})",
|
||||
kind,
|
||||
|
@ -2,7 +2,11 @@ error: Undefined Behavior: trying to reborrow <TAG> for SharedReadOnly permissio
|
||||
|
|
||||
= help: this indicates a potential bug in the program: it performed an invalid operation, but the 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: <TAG> was created by a retag at offsets [0x0..0x0]
|
||||
--> $DIR/zst_slice.rs:LL:CC
|
||||
|
|
||||
LL | assert_eq!(*s.get_unchecked(1), 2);
|
||||
| ^^^^^^^^^^^^^^^^^^
|
||||
= note: inside `core::slice::<impl [i32]>::get_unchecked::<usize>` at rustc_src/src/slice/mod.rs:LL:CC
|
||||
note: inside `main` at $DIR/zst_slice.rs:LL:CC
|
||||
--> $DIR/zst_slice.rs:LL:CC
|
||||
|
Loading…
Reference in New Issue
Block a user