-
Notifications
You must be signed in to change notification settings - Fork 325
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
Assigning Some instead of calling replace
triggers Miri under some unsafe conditions
#2722
Comments
By writing it that way, you are creating a two-phase borrow (that's how Rust handles implicit mutable references for function calls). Sadly two-phase borrows are incompatible with Stacked Borrows so Miri treats them like raw pointers, which in this case then happens to allow the code. That is a Stacked Borrows/Miri limitation, and we are actively working on a better aliasing model that can properly track two-phase borrows. If you write That also explains why these wrapping functions help -- they, too, will be called using two-phase borrows. This is all not great, and Miri should error (or not error) consistently here, but turns out that is actually quite hard to achieve and we are not there yet. The problem with this code is that you are doing
This seems to indicate a fundamental misunderstanding: for aliasing to be respected, there must be no other pointers or references to this data that are being used. An So, the safety comment also needs to explain that none of the aliasing pointers are going to be used for the lifetime of this mutable reference. |
Thanks for your answer, that was extremely helpful! |
I don't know that there is one tracking issue, but you can start from here and follow links: rust-lang/rust#96268 (your opening this issue is basically the problem I was concerned about) This is a classic problem with sanitizers: When you expect them to complain but they don't, it's nearly impossible to figure out why. We do have some special functions (they are documented in the README) which you can use to print out borrow stacks at runtime. Though I wonder if |
The tracking issue is at rust-lang/unsafe-code-guidelines#85. It's a model issue, not a Miri implementation issue, which is why it is in another repo. |
This is hopefully a small enough repro snippet:
I am experimenting with unsafe, so apologies if the code/comments above are wrong or misleading.
Running
cargo miri test
, possible UB is detected becauseparent_today.child.replace(Box::new(Self { value, child: None }));
then Miri is happy and reports no issue. Could I get some insight on this?which just wrap the two different behaviours of the previous point, then Miri reports no issue when using either (in place of the incriminated assignment). In particular, I would expect
declare_child_too
to trigger the same error reported originally.The text was updated successfully, but these errors were encountered: