-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InvalidUndefBytes: Track size of undef region used #71610
Conversation
One thing I am wondering about in terms of the Miri diagnostics that will be based on this: is "first uninit range" really the most useful piece of information? I could imagine it would be more useful to learn what the full memory range of the access was, and there in that access the uninit stuff is. @divergentdave you seem to have a good use for these diagnostics as you initially contributed them, what do you think? |
This comment has been minimized.
This comment has been minimized.
@divergentdave this PR needs rebasing to resolve conflicts and there are some review comments to take care of. No pressure though, if you need more time that's all right. :) |
8e28d0b
to
3a12f2d
Compare
I rebased everything up and changed the InvalidUninitBytes variant to hold an Option of a new struct, which now holds pointers and sizes for both the original memory access and the subset that was uninitialized. |
3a12f2d
to
1c04c6d
Compare
1c04c6d
to
8f77f60
Compare
@@ -384,7 +397,7 @@ pub enum UndefinedBehaviorInfo<'tcx> { | |||
/// Using a string that is not valid UTF-8, | |||
InvalidStr(std::str::Utf8Error), | |||
/// Using uninitialized data where it is not allowed. | |||
InvalidUninitBytes(Option<Pointer>), | |||
InvalidUninitBytes(Option<Box<UninitBytesAccess>>), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To avoid the size hit, boxing certainly makes sense. But OTOH we have a allocates
function below to make sure that errors coming up during ConstProp do not allocate as that would be a perf hit. But I think this error here actually can come up during ConstProp so we probably cannot add it there. @oli-obk what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I updated allocates()
and the tests still pass. It seems like InvalidUninitBytes(None) from reading a Scalar is far more common, and the Some case comes up with things like FFI with libc. Perhaps that means it doesn't come up in ConstProp?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm... that might be a coincidence though...
but {} byte{} {} uninitialized starting at {}, \ | ||
and this operation requires initialized memory", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but {} byte{} {} uninitialized starting at {}, \ | |
and this operation requires initialized memory", | |
but {} byte{} {} uninitialized starting at {}, \ | |
and this operation requires initialized memory", |
8f77f60
to
9d56dac
Compare
} | ||
|
||
#[cfg(target_arch = "x86_64")] | ||
static_assert_size!(UndefinedBehaviorInfo<'_>, 32); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually what I meant is doing this for InterpError
. We don't really care about the individual variants.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops, got it
9d56dac
to
0148a7f
Compare
@@ -556,6 +577,9 @@ impl dyn MachineStopType { | |||
} | |||
} | |||
|
|||
#[cfg(target_arch = "x86_64")] | |||
static_assert_size!(InterpError<'_>, 40); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uff, 40 bytes. @oli-obk we might have to work on reducing that before @nnethercote catches us.^^
Looking good, thanks! |
📌 Commit 0148a7f has been approved by |
Rollup of 4 pull requests Successful merges: - rust-lang#71610 (InvalidUndefBytes: Track size of undef region used) - rust-lang#72161 (Replace fcntl-based file lock with flock) - rust-lang#72306 (Break tokens before checking if they are 'probably equal') - rust-lang#72325 (Always generated object code for `#![no_builtins]`) Failed merges: r? @ghost
InvalidUndefBytes: Update to match rustc changes This is a companion PR for rust-lang/rust#71610. This won't build yet, but we may need these changes in a future rustup.
This PR adds a size to
UndefinedBehaviorInfo::InvalidUndefBytes
, to keep track of how many undefined bytes in a row were accessed, and changes a few methods to pass this information through. This additional information will eventually be used in Miri to improve diagnostics for this UB error. See also rust-lang/miri#1354 for prior discussion.I expect Miri will break the next time its submodule is updated, due to this change to the
InvalidUndefBytes
. (The current commit for src/tools/miri predates rust-lang/miri#1354, and thus does not try to destructure theInvalidUndefBytes
variant) I have a corresponding change prepared for that repository.r? @RalfJung