Show the offset, length and memory of uninit read errors #142673
Conversation
rustbot
added
S-waiting-on-review
| throw_ub!(InvalidUninitBytes(None)); | ||
| throw_ub!(InvalidUninitBytes(match op.to_op(self)?.as_mplace_or_imm() { | ||
| Left(mplace) => mplace.ptr().provenance.and_then(|prov| { | ||
| let start = mplace.ptr().into_parts().1; | ||
| let size = op.layout().size; | ||
| let range = alloc_range(start, size); | ||
| Some((prov.get_alloc_id()?, BadBytesAccess { access: range, bad: range })) | ||
| }), | ||
| Right(_) => None, | ||
| })) |
There was a problem hiding this comment.
This one doesn't show up in diagnostics, but it seemed good to change it, too
There was a problem hiding this comment.
Why doesn't it show up in diagnostics? Aren't all the miri output diffs caused by exactly this?
There was a problem hiding this comment.
Ah no, that diff is probably caused by the read_scalar change.
If this logic here can't be tested, I'd rather remove it, given that it is currently wrong due to how it uses into_parts.
There was a problem hiding this comment.
#142839 gets rid of it
There was a problem hiding this comment.
This is read_immediate, #142839 does nothing there...?
There was a problem hiding this comment.
oh right, I mixed up things.
hmm. yea I think I just tried this one because I thought it should be hit somewhere. So I'll turn it into a span_bug
This comment has been minimized.
This comment has been minimized.
|
grml. I haven't been able to run miri's dep tests in-tree in forever. Always sth about libc not found. Will try to bless the others and hope none of these need blessing |
|
The Miri subtree was changed cc @rust-lang/miri |
This comment has been minimized.
This comment has been minimized.
| throw_ub!(InvalidUninitBytes(None)); | ||
| throw_ub!(InvalidUninitBytes(match op.to_op(self)?.as_mplace_or_imm() { | ||
| Left(mplace) => mplace.ptr().provenance.and_then(|prov| { | ||
| let start = mplace.ptr().into_parts().1; | ||
| let size = op.layout().size; | ||
| let range = alloc_range(start, size); | ||
| Some((prov.get_alloc_id()?, BadBytesAccess { access: range, bad: range })) | ||
| }), | ||
| Right(_) => None, | ||
| })) |
There was a problem hiding this comment.
Why doesn't it show up in diagnostics? Aren't all the miri output diffs caused by exactly this?
| throw_ub!(InvalidUninitBytes(None)); | ||
| throw_ub!(InvalidUninitBytes(match op.to_op(self)?.as_mplace_or_imm() { | ||
| Left(mplace) => mplace.ptr().provenance.and_then(|prov| { | ||
| let start = mplace.ptr().into_parts().1; |
There was a problem hiding this comment.
This is not correct -- depending on which type of provenance this is, start will be either relative to the allocation, or absolute. into_parts has a doc comment warning about this. :) Maybe we should rename it into_raw_parts or so to make it more clear that this API is somewhat dicey.
|
☔ The latest upstream changes (presumably #143091) made this pull request unmergeable. Please resolve the merge conflicts. |
|
@rustbot author |
rustbot
added
S-waiting-on-author
|
Reminder, once the PR becomes ready for a review, use |
r? @RalfJung
I want to improve memory dumps in general. Not sure yet how to do so best within rust diagnostics, but in a perfect world I could generate a dummy in-memory file (that contains the rendered memory dump) that we then can then provide regular rustc
Spans to. So we'd basically report normal diagnostics for them with squiggly lines and everything.