Miri: fix error on dangling pointer inbounds offset #114333
Conversation
rustbot
added
S-waiting-on-review
|
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri The Miri subtree was changed cc @rust-lang/miri Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri |
also simplify the in-bounds checking in Miri's borrow trackers
RalfJung
force-pushed
the
dangling-ptr-offset
branch
from
6d016a3 to
8496292
Compare
| --> $DIR/dangling_pointer_offset.rs:LL:CC | ||
| | | ||
| LL | let x = unsafe { p.offset(42) }; | ||
| | ^^^^^^^^^^^^ out-of-bounds pointer arithmetic: ALLOC has been freed, so this pointer is dangling |
There was a problem hiding this comment.
This is the key change, previously this talked about "pointer to alloc859 was dereferenced after this allocation got freed"
|
@bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (64ad036): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 648.769s -> 647.763s (-0.16%) |
We used to claim that the pointer was "dereferenced", but that is just not true.
Can be reviewed commit-by-commit. The first commit is an unrelated rename that didn't seem worth splitting into its own PR.
r? @oli-obk