-
Notifications
You must be signed in to change notification settings - Fork 353
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
Cannot run even basic Tokio programs #602
Comments
I kind of feel like there's going to be an infinite amount of these, considering that any FFI function won't be supported. I don't have a good solution other than some crazy pluggable module system... |
Does this try to spawn a thread later? We can stub out |
I... literally have no idea ;-) This was just the first non-trivial thing I thought to test the playground's support of Miri + crates with. My magical ideal world is the ability to run Miri on some random bit of code and know if I did the bad thing. |
So, we got a little further. I guess it would be doable to start magically creating function pointers to "dynamically loaded libraries" (like we care what any code thinks about the platform they are running on).
|
Dynamically loading functions works now... but huh?
|
What is the type of |
I found the issue. Our pointer vs int comparison code gets the alignment of the allocation in question, and will not allow you to compare a function pointers 0-size 1-align pointer against a literal
|
I added a hack to also allow I even think the stacked borrows are right. I mean we are transmuting away the "celliness" of that field. So now we have an immutable reference that can just change under us. It won't of course, due to what the unsafe code promises, but still. I don't know why that function doesn't just return a copy of
|
So Tokio makes the assumption that a function pointer will never be 1? Uh... that's probably fair on most platforms, but doesn't strike me as something we should put into the spec. I am not sure what the best way is for Miri to reflect such assumptions. This is directly related to being able to model "well-known addresses" as they might exist on embedded platforms. |
You mean like we shouldn't even treat zero specially? 🤣 |
Well, that is not just a Miri thing. ;) |
@shepmaster could you try again where your test fails in Miri these days? The stacktrace in the OP indicates |
Ah, I didn't know tokio is available on the playground. I updated the OP. The failing foreign function these days is |
By the way there's a pull request to fix this in Tokio now, so running the Tokio runtime without I/O or time support should be possible in Miri soon, hopefully. |
That's pretty cool. :) Though... what does tokio even do then if there's no I/O or timers?^^ (Please forgive the naive question, I am not a tokio user.) |
@RalfJung Tokio just provides nice wrappers around raw futures in general. One example is its attribute macros, it's much nicer to write: #[tokio::test]
async fn test_something() {
a().await;
b().await;
} than the manual version: fn test_something() {
futures_executor::block_on(async {
a().await;
b().await;
});
} It also supports spawning futures on the executor with |
It is currently possible to run Tokio under miri with fn main() {
let rt = tokio::runtime::Builder::new_current_thread()
.build()
.unwrap();
rt.block_on(real_main());
}
async fn real_main() {
...
}
|
I'd like to work on this issue. |
implement minimal epoll_create1 shim Implements minimal shim for #602
Implement epoll_wait This PR continues working on #602. This is an implementation for `sleep`, though admittedly not a good one. It just does busy waiting.
Implement epoll_wait This PR continues working on rust-lang/miri#602. This is an implementation for `sleep`, though admittedly not a good one. It just does busy waiting.
Good next steps for Tokio support would be:
I think that should bring us pretty close to closing this issue -- though I would say that supporting timers should also be done before we consider "basic" support to work. Async file system or network access is definitely beyond the scope of this issue though. |
## This Commit Leverages [this comment][0] to allow tests to be run with Miri. ## Why? The regular macro enables a runtime that cannot be run with Miri yet and we'd like to catch any undefined behavior we can. [0]: rust-lang/miri#602 (comment)
fails with this error (Playground): (Updated on 2022-07-06)
epoll_create1(2)
The text was updated successfully, but these errors were encountered: