-
Notifications
You must be signed in to change notification settings - Fork 385
Help understanding MIRI failure in FFI boundaries. #1800
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
Comments
Yeah, Stacked Borrows errors can be hard to debug... The first step is to reproduce the error without Btw, to paste console output into a GitHub issue, use a code block -- these are marked with |
Thanks a lot for the quick reply, @RalfJung So, the flow of this tag goes as follows:
On the test that passes, the step 3. is only done once. This seems to be the complain, that are poping a unique twice. What I do not understand is why this is a concern: we are just defering the pointer of pointers to read different positions; we do not actually store that pointer anywhere when reading it. Maybe another way of asking this: what is a Stacked Borrows error? ^_^ |
Stacked Borrows is a candidate for the Rust aliasing model. A Stacked Borrows error means your code (or code you called) does something which is in contradiction with those aliasing rules. Could you show the output with "track-pointer-tag"? |
Thanks for the explanation. Sorry for the wall of text below: EDIT: see below |
Sorry for the noise; that was a wrong tag; I changed some unrelated code, which changed the tag number; correct below:
|
The first suspicious aspect of this code that I noticed is here The first line creates a raw pointer into the I assume what happens is that subsequently, you are using both the raw pointer and the |
I hope the question has been answered at least to some extend, so I will close the issue. Feel free to reopen if that is premature! |
At arrow2, we have an FFI to interact with other languages, and are observing a failure in a single check while performing a roundtrip across FFI boundaries (i.e. Rust is both the producer and consumer), and we are uncertain what the exact problem is.
The message is
I was wondering if anyone knows whether this is a true positive and why. It is not entirely clear to me what the
.md
file means, and would appreciate any tips wrt to this.I am sorry I am unable to offer a simple example, but the problem itself is non-trivial as it emerges during a non-trivial release callback mechanism, and we do not observe it in all types (e.g. the test
ffi::array::tests::test_u32
passes).To reproduce on the CI, clone it in github and comment this line .
The text was updated successfully, but these errors were encountered: