Skip to content
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

Unknown which places in tokio::sync cause deadlock #5479

Closed
8 tasks
amab8901 opened this issue Feb 19, 2023 · 1 comment
Closed
8 tasks

Unknown which places in tokio::sync cause deadlock #5479

amab8901 opened this issue Feb 19, 2023 · 1 comment
Labels
A-tokio Area: The main tokio crate C-bug Category: This is a bug. M-sync Module: tokio/sync

Comments

@amab8901
Copy link
Contributor

amab8901 commented Feb 19, 2023

This is a branch from #5429.

Description:
There are some types in tokio::sync which keep a shared state behind a mutex and expose methods to modify it through a shared reference. Two instances were uncovered. One was solved and merged, while the other one is waiting to avoid merge conflict. Now we need to identify all other instances in tokio::sync where this bug occurs. I found that the key thing that is held in common among lines that produce this deadlock is that they have a statement containing the waiter keyword. Applying appropriate changes to each of the below lines might result in a guarantee of this deadlock bug never occurring again in tokio::sync.

Task: go through every type in tokio::sync and check whether they have this bug.

Lines containing waker in statement:
Lines containing waker in statement:

  • mpsc/chan.rs
    • 327 (initialize)
  • mpsc/unbounded.rs
    • no statements
  • task/atomic_waker.rs
    • 195 (initialize)
    • 200 (initialize)
    • 204 (risky assignment)
    • 237 (initialize)
    • 246 (old waker saved)
    • 251 (condition)
    • 262 (condition)
    • 304 (condition)
    • 320 (initialize)
  • barrier.rs
    • no statements
  • batch_semaphore.rs
    • 232 (initialize)
    • 233 (condition)
    • 285 (initialize)
    • 306 (condition)
    • 452 (reformulation)
    • 459 (old waker saved)
  • broadcast.rs
    • 772 (initialize)
    • 903 (condition)
    • 915 (risky assignment)
    • 1169 (condition)
  • notify.rs
    • 464 (condition)
    • 503 (initialize)
    • 533 (condition)
    • 603 (initialize)
    • 771 (risky assignment)
    • 835 (risky assignment)
    • 868 (condition)
    • 874 (risky assignment)
    • 939 (condition)
  • oneshot.rs
    • 412 (initialize)
    • 419 (initialize)
    • 427 (risky write)
@amab8901 amab8901 added A-tokio Area: The main tokio crate C-bug Category: This is a bug. labels Feb 19, 2023
@Darksonn Darksonn added the M-sync Module: tokio/sync label Feb 19, 2023
@amab8901
Copy link
Contributor Author

so these are the lines where I think the deadlock bug is most likely to appear:

  • high-risk shortlist:
    • task/atomic_waker.rs
      • 204 (risky assignment)
    • broadcast.rs
      • 915 (risky assignment)
    • notify.rs
      • 771 (risky assignment)
      • 835 (risky assignment)
      • 874 (risky assignment)
    • oneshot.rs
      • 427 (risky write)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-bug Category: This is a bug. M-sync Module: tokio/sync
Projects
None yet
Development

No branches or pull requests

2 participants