-
Notifications
You must be signed in to change notification settings - Fork 54
Issues running tests in miri #61
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
I had a chat with Oli on Zulip, and he suggested a couple things to try. I'll give it a hack this evening, unless y'all have any silver bullet ideas :D |
Hi @jamesmunns, thanks a lot for raising this issue! I agree that miri checks would be quite useful for this crate, especially with the proposed strict provenance rules. Right now, I think the main problem is that we're using
If I comment out the
I'm not sure what's causing this, but it's probably an indication for some undefined behavior. Without miri, all the tests still pass. I try to investigate this further when I have some time. |
I can't add too much, only vague memory, but my work on miri was concentrated on a single code path. Many other tests may still have failed MIRI even at that time and due what I assumed to be false positives (?) from manual alignment stricter than allocation alignments, I didn't have an incentive to look too deeply. Just attributed them to known issues, waiting for symbolic execution of address calculations to resolve these at some point in MIRI (align_to can't be used internally so the current |
Thanks to both of you! After posting this I promptly got sick, but do hope to hack on this soon. I'll take a look at your Miri branch - replacing the usizes was where Oli suggested to start. I'll report back if I make any headway! |
Following up on this in #62 |
Hey! I'm building a sort of "liballoc replacement" for my work on MnemOS, and I'm both using linked_list_allocator, and doing some pretty gnarly unsafe stuff on top of it. Because of this, I wanted to get miri testing going to make sure I am not shooting myself in the foot, but it seems pretty upset about linked_list_allocator in general.
Even without the newer strict provenance checks, I'm getting errors like this just constructing the heap in the tests:
This seems pretty challenging to deal with: Miri is complaining that the allocator is holding a pointer with provenance to the entire range, and that writing the first
Hole
in that range is invalidating the tag.I saw that you and @HeroicKatora had done some work to make miri happy in the past, I'm not sure if this has changed due to certain behaviors becoming defaults (stacked borrows maybe?).
I'd be happy to help getting these passing again if I can!
The text was updated successfully, but these errors were encountered: