Stream: general

Topic: running miri on capnp


David Renshaw (Jan 16 2020 at 02:56, on Zulip):

@RalfJ I am impressed with how easy it easy to run miri on things these days. Bravo! And thanks for the suggestion.

David Renshaw (Jan 16 2020 at 03:09, on Zulip):
error: Miri evaluation error: no item granting read access to tag <untagged> found in borrow stack
    --> /home/dwrensha/src/capnproto-rust/capnp/src/private/layout.rs:2863:18
     |
2863 |                 ((*b) & (1u8 << (boffset % BITS_PER_BYTE as u32) as usize)) != 0
     |                  ^^^^ Miri evaluation error: no item granting read access to tag <untagged> found in borrow stack
David Renshaw (Jan 16 2020 at 03:10, on Zulip):

oof. I'm not sure what that means.

oli (Jan 16 2020 at 06:10, on Zulip):

Oh no, an untagged. Not sure how to debug these

oli (Jan 16 2020 at 06:12, on Zulip):

Is b a raw pointer by any chance?

oli (Jan 16 2020 at 06:13, on Zulip):

Often this error means that after you created b , you wrote via the original reference that you got b from

RalfJ (Jan 16 2020 at 09:03, on Zulip):

it also often means that you used a raw pointer outside of its "range of validity"

RalfJ (Jan 16 2020 at 09:04, on Zulip):

like, maybe you did &x[0] as *const _ and then offset that pointer -- which is illegal, only x[0] may be accessed by raw ptrs

RalfJ (Jan 16 2020 at 09:04, on Zulip):

if you want to access the entire thing, call x.as_ptr()

David Renshaw (Jan 16 2020 at 12:13, on Zulip):

Yep, that was it! https://github.com/capnproto/capnproto-rust/commit/72480efb3514d32278bd2502a7b90b22a34d12b8

David Renshaw (Jan 16 2020 at 12:13, on Zulip):

why is &x[0] as *const _ illegal?

RalfJ (Jan 16 2020 at 12:33, on Zulip):

@David Renshaw the issue where we track that is https://github.com/rust-lang/unsafe-code-guidelines/issues/134. the wider context is https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md and the blog posts and papers it links.

RalfJ (Jan 16 2020 at 12:34, on Zulip):

basically, we want the compiler to optimize based on assumptions like "&mut pointers are unique", and to that effect we have to be very careful what we actually allow to be done with raw pointers

RalfJ (Jan 16 2020 at 12:35, on Zulip):

note that the cast itself is perfectly legal, as is accessing the element you casted, but going outside that range is not allowed by the current model. there might be other models that do allow this, but likely at the cost of significant extra complexity (so, making it harder to understand the model) and/or at the cost of optimization potential.

David Renshaw (Jan 16 2020 at 12:35, on Zulip):

:thumbs_up:

RalfJ (Jan 16 2020 at 12:36, on Zulip):

when I saw choices like this while designing Stacked Borrows, I usually decided to opt for the more restrictive choice. it is much easier to relax such constraints later than to tighten them.

RalfJ (Jan 16 2020 at 12:36, on Zulip):

basically, I wanted to see how much I could get away with :P

RalfJ (Jan 16 2020 at 12:39, on Zulip):

I added this to the list in the issue... but the list is pretty incomplete, this is probably the stacked borrows issue that comes up most freuqently (alongside https://github.com/rust-lang/unsafe-code-guidelines/issues/133)

RalfJ (Jan 16 2020 at 12:40, on Zulip):

re: https://github.com/capnproto/capnproto-rust/commit/3ea257068e9f7b6f3968a4ddb4669ff54ad79175, I wonder if there is a way to reduce the number of iterations or so? to get at least a tiny bit of fuzzing done with miri?

RalfJ (Jan 16 2020 at 12:40, on Zulip):

but yeah, I've had to disable such tests in other repos as well :/

RalfJ (Jan 16 2020 at 12:41, on Zulip):

RalfJ I am impressed with how easy it easy to run miri on things these days. Bravo! And thanks for the suggestion.

(totally forgot to reply) thanks, that is encouraging :)

David Renshaw (Jan 16 2020 at 12:42, on Zulip):

I was bracing myself for needing to get some kind of xargo setup going. It was amazing to be able to rustup component add and have it just work.

RalfJ (Jan 16 2020 at 12:43, on Zulip):

yeah I hacked that auto-setup during RustFest Rome and later wondered why I hadn't done it earlier :D

RalfJ (Jan 16 2020 at 12:45, on Zulip):

it's still just as ugly under the hood as it used to be, but hidden better^^

David Renshaw (Jan 16 2020 at 12:52, on Zulip):

The other immediate thing that miri is finding is that I create (but never deference) pointers that are exactly one element beyond the end of an allocation. I can understand why miri want me to not do that (and I'll fix my code), but just for perspective: this is following a c++ pattern of using "1 past end of container" as the end iterator container.end().

oli (Jan 16 2020 at 13:18, on Zulip):

one past the end of the container pointers are ok: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9b6b532e5b20d76ed422f7a86580af07

RalfJ (Jan 16 2020 at 17:55, on Zulip):

@David Renshaw by "pointer", do you mean "reference"? because references in Rust are a bit like references in C++ in that they must be dereferencable. the one-past-the-end thing is invalid for both. it is valid for raw pointers though.

David Renshaw (Jan 16 2020 at 23:33, on Zulip):

Indeed, my code constructs such invalid references! I didn't realize it because it immediately casts them to raw pointers.

RalfJ (Jan 17 2020 at 08:43, on Zulip):

@David Renshaw ah... you might be interested in https://github.com/rust-lang/rfcs/pull/2582

Last update: Feb 25 2020 at 04:20UTC