-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Deadlock when dropping Runtime #2046
Comments
The channel will only end when all senders are dropped (see docs for This works: |
This totally makes sense. I hopped to conclusion a bit too fast hunting down a deadlock I have by dropping a |
Well, I haven't found a minimal example yet, but I have found the source. It goes through the |
I think I got it. This produces the same backtrace: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d91e66ff621acdbfe836decf028c9a04 Backtrace: https://gist.github.com/appaquet/87de2b93871c47ae5e81f849fe8c8a93 This doesn't happen with my fix here: master...appaquet:queue-reintrant-deadlock |
I though 855d39f in 0.2.8 may have fixed the issue, but I still get the same deadlock. Dropping the lock before calling the closure still fixes the issue in my project: master...appaquet:queue-reintrant-deadlock |
Thanks, I will take a look |
Ah, thanks so much for the minimal repro. I missed it originally. I should have a PR up soon. |
Previously, when the threaded scheduler was in the shutdown process, it would hold a lock while dropping in-flight tasks. If those tasks included a drop handler that attempted to wake a second task, the wake operation would attempt to acquire a lock held by the scheduler. This results in a deadlock. Dropping the lock before dropping tasks resolves the problem. Fixes #2046
PR is up |
Previously, when the threaded scheduler was in the shutdown process, it would hold a lock while dropping in-flight tasks. If those tasks included a drop handler that attempted to wake a second task, the wake operation would attempt to acquire a lock held by the scheduler. This results in a deadlock. Dropping the lock before dropping tasks resolves the problem. Fixes #2046
Version
0.2.6
Platform
Linux
Description
See this gist for minimum code to reproduce and backtrace. It seems to only happen if thespawn_blocking
block uses a cloned mpsc sender.Inconsistently, a deadlock occurs when dropping a
Runtime
in a configuration of channels andspawn_blocking
as seen here. It looks like it tries to go through thetokio::runtime::thread_pool::queue::global::Queue<T>
pointers
mutex twice in the same stack when going through the closed channel code path. This fix seems to be fixing the issue.Stack trace
The text was updated successfully, but these errors were encountered: