-
Notifications
You must be signed in to change notification settings - Fork 346
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
Print hex dump of alloc on reading undef bytes #1354
Print hex dump of alloc on reading undef bytes #1354
Conversation
Could you copy-paste an example output here so I can get a feeling for what this error looks like? |
Here's the output as-is Console output
|
Hm I see. Nice start, but I think we can do better. :D So I think reordering this as I suggested above doesn't make the output worse, and it helps code structure, so IMO we should go with that. Also, given that the allocation dump prints offsets in hex, we should also show the offset in hex, so the user does not have to do that conversion themselves. But it almost looks like Later it might be nice to point to the right spot in that dump, but that's not a must-have. |
63c68d0
to
9057dae
Compare
I swapped the order, here's what it looks like now. Output
That offset is in hexadecimal, it's formatted by this https://github.com/rust-lang/rust/blob/b2e36e6c2d229126b59e892c9147fbb68115d292/src/librustc_middle/mir/interpret/pointer.rs#L122-L132. I can submit a PR to add a leading "0x" over there. |
Yes please do.
Great!
Do you think that would be useful? Suggestions welcome. In the future I think it'd be nice to give not just the start offset but also the end offset. That will require tracking the access size in |
…RalfJung Add leading 0x to offset in Debug fmt of Pointer Currently the `Debug` format for `Pointer` prints its offset in hexadecimal, for example, `alloc38657819+e2` or `alloc35122748+64`. This PR adds a leading `0x` to the offset, in order to make it apparent that it is indeed a hexadecimal number. This came up during discussion of rust-lang/miri#1354. r? @RalfJung
…RalfJung Add leading 0x to offset in Debug fmt of Pointer Currently the `Debug` format for `Pointer` prints its offset in hexadecimal, for example, `alloc38657819+e2` or `alloc35122748+64`. This PR adds a leading `0x` to the offset, in order to make it apparent that it is indeed a hexadecimal number. This came up during discussion of rust-lang/miri#1354. r? @RalfJung
OK, added the explanatory message and added a compile-fail test that exercises it. Output:
|
I took a look at this briefly, one issue is that the |
Here's my first pass on the above, haven't opened a PR for it yet. rust-lang/rust@8e28d0b |
src/diagnostics.rs
Outdated
@@ -118,7 +118,12 @@ pub fn report_error<'tcx, 'mir>( | |||
let result = report_msg(ecx, &format!("{}: {}", title, msg), msg, helps, true); |
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.
report_msg
always returns None
, no idea why it even has a return type... we can clean that up later though if you prefer.
That looks like a great start, could you open a PR? |
Thanks. :) |
📌 Commit e267fb4 has been approved by |
☀️ Test successful - checks-travis, status-appveyor |
…ge, r=RalfJung InvalidUndefBytes: Track size of undef region used 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 the `InvalidUndefBytes` variant) I have a corresponding change prepared for that repository. r? @RalfJung
Here's a small addition I made locally to the UB diagnostics, in case you're interested in it. This PR calls
dump_alloc()
on the relevant allocation if Miri fails on UB due to reading undefined bytes. This came in handy when diagnosing such an issue in a large program using unsafe Rust, in part because it wasn't deterministic enough to use-Zmiri-track-alloc-id=
. If you'd like to put this behind another -Z flag, let me know.