Stream: t-lang/wg-unsafe-code-guidelines

Topic: borrows invalidating raw pointers


Matt Brubeck (Apr 23 2020 at 17:20, on Zulip):

I have some questions about when raw pointers are invalidated, based on comments by @RalfJ in https://github.com/servo/rust-smallvec/pull/213

This extremely minimal case does not cause a MIRI error. Should it? https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=f3b2679b6c99a4ce21fc45079b6d2a05

Matt Brubeck (Apr 23 2020 at 17:30, on Zulip):

Even this version passes MIRI, so it's not just that the previous version somehow avoids "actually" creating an &mut:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e25d3f2a318af941fbdd332d57f9346a

Matt Brubeck (Apr 23 2020 at 17:53, on Zulip):

If I'm understanding this behavior right, creating a new Unique borrow invalidates the previous raw pointer (clearing the borrow stack), but then the cast from &mut to *mut retags this borrow, so the stack is now [(Untagged: SharedReadWrite)] again, and this makes the previously-invalidated raw pointer valid again:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=bae8fa79cc8c5d1023e8cbd11a050ca6

Yato (Apr 23 2020 at 19:54, on Zulip):

Yes, that first write to p0 should invalidate p1. MIRI doesn't track raw pointers as well as it should, so MIRI doesn't detect these sorts of aliasing bugs yet.

Yato (Apr 23 2020 at 19:54, on Zulip):

If I'm understanding this behavior right, creating a new Unique borrow invalidates the previous raw pointer (clearing the borrow stack), but then the cast from &mut to *mut retags this borrow, so the stack is now [(Untagged: SharedReadWrite)] again, and this makes the previously-invalidated raw pointer valid again:

Yes, all raw pointers have the same tag (which is untagged) right now, so making a new raw pointer to the same location revives old raw pointers incorrectly.

Matt Brubeck (Apr 23 2020 at 19:59, on Zulip):

Thanks!

RalfJ (Apr 24 2020 at 14:00, on Zulip):

@Matt Brubeck note however that to match what LLVM does with noalias, we need to eventually also track raw pointers better

RalfJ (Apr 24 2020 at 14:00, on Zulip):

and then that kind of code would stop working

RalfJ (Apr 24 2020 at 14:02, on Zulip):

the trouble is that we have to somehow stop tracking around ptr-to-int-casts, otherwise we break code that is definitely correct. LLVM gets this wrong, though, and it is unclear what the best approach is here ("unclear" as in "this is an area of PL research").

Matt Brubeck (Apr 24 2020 at 14:19, on Zulip):

Got it, thanks.

Last update: Jun 05 2020 at 23:15UTC