Show the offset, length and memory of uninit read errors #142673
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
oli-obk
commented
Jun 18, 2025
Comment on lines
666
to
674
| 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
There was a problem hiding this comment.
ok, digging into this got more interesting. I added two more commits. TLDR: we only ever use Immediate::Uninit for zsts or for uninit locals. But reading uninit locals only happens by converting them to Operand, which handles uninit immediates if processed by erroring.
There was a problem hiding this comment.
That's kind of an accidental invariant though, I think... is it worth relying on?
There was a problem hiding this comment.
It allows some simplifications. lmk what you think about the latest commits and I can either restore the previous zst/uninit design, or we keep it and revisit if we notice there's something better to do with it (or matthias manages to fuzz us examples of how that code is actually reachable for non-zsts)
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.
oli-obk
force-pushed
the
uninit-read-mem
branch
2 times, most recently
from
ff2e26b to
0120c8e
Compare
RalfJung
reviewed
Jun 27, 2025
Comment on lines
666
to
674
| 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 |
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
This comment has been minimized.
This comment has been minimized.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
☔ The latest upstream changes (presumably #142839) made this pull request unmergeable. Please resolve the merge conflicts. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.