-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Miri fails when unwinding in safe code #6603
Comments
can you test if this PR helps? #6524 |
It seems to. Hopefully miri isn't just spuriously passing again. |
For posterity, here's the miri output, since GitHub Action's logs are TLL'ed. |
I wonder if the issue is that we should be using |
Looks like miri still fails periodically, even with #6524: https://github.com/JoJoJet/bevy/actions/runs/3484882520/jobs/5829897858
|
My next guess to why this is happening is that the Task abstraction just asks the future to cancel when it is dropped, but doesn't wait for the future to cancel. We might need to use FailableTask instead and explicitly wait for them to cancel when the scope is dropped. |
can you test if this new PR helps? #6696 edit: |
Seems like that fixed the unsoundness (miri passed 10 times). This test still fails inconsistently. It's supposed to panic, but sometimes it doesn't. I don't know if the panic is getting swallowed up, or if the test itself is just inconsistent. |
would a https://doc.rust-lang.org/std/sync/struct.Barrier.html work better here than a sleep? Might be getting swallowed, if we're not propagating errors correctly anymore. The code for that in scope has significantly changed behavior with these PR's. |
Didn't know about that type, TIL. After investigating, I think it's just that the test is inconsistent when run on CI. If the test is only given one thread, then it won't panic as expected and the test fails. This became more obvious after I changed it to use a All this to say, I believe that #6696 fixes this issue. |
# Objective - Fixes #6603 ## Solution - `Task`s will cancel when dropped, but wait until they return Pending before they actually get canceled. That means that if a task panics, it's possible for that error to get propagated to the scope and the scope gets dropped, while scoped tasks in other threads are still running. This is a big problem since scoped task can hold life-timed values that are dropped as the scope is dropped leading to UB. --- ## Changelog - changed `Scope` to use `FallibleTask` and await the cancellation of all remaining tasks when it's dropped.
# Objective - Fixes #6603 ## Solution - `Task`s will cancel when dropped, but wait until they return Pending before they actually get canceled. That means that if a task panics, it's possible for that error to get propagated to the scope and the scope gets dropped, while scoped tasks in other threads are still running. This is a big problem since scoped task can hold life-timed values that are dropped as the scope is dropped leading to UB. --- ## Changelog - changed `Scope` to use `FallibleTask` and await the cancellation of all remaining tasks when it's dropped.
# Objective - Fixes bevyengine#6603 ## Solution - `Task`s will cancel when dropped, but wait until they return Pending before they actually get canceled. That means that if a task panics, it's possible for that error to get propagated to the scope and the scope gets dropped, while scoped tasks in other threads are still running. This is a big problem since scoped task can hold life-timed values that are dropped as the scope is dropped leading to UB. --- ## Changelog - changed `Scope` to use `FallibleTask` and await the cancellation of all remaining tasks when it's dropped.
Bevy version
f7c8eb7
What you did
I created this test:
What were you expecting
The multiple instances of
assert_non_sync
should conflict with each other and safely cause a panic.What went wrong
The following miri failure is triggered: https://github.com/JoJoJet/bevy/actions/runs/3457086747/jobs/5770279259
Additional information
I investigated a bit further on this branch. The test seems to randomly not fail sometimes, but eventually this failure was triggered:
https://github.com/JoJoJet/bevy/actions/runs/3457314695/jobs/5770662745
Some theories from @BoxyUwU https://discord.com/channels/691052431525675048/749335865876021248/1041500126880989184.
The text was updated successfully, but these errors were encountered: