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:
bors 2022-05-30 23:43:51 +00:00
commit aa589d3dc7
2 changed files with 25 additions and 2 deletions

View File

@ -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,

View File

@ -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