-
Notifications
You must be signed in to change notification settings - Fork 979
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 in 0.20.0 and trunk #5662
Comments
CC @jimblandy, who's been working on issues like this recently. |
Could you pull out from those stacks the locks each thread is holding, if any? |
Actually, it might suffice simply to know which lock each thread is trying to acquire, and I could figure out which other ones it must be holding. |
The deadlock appears to be caused by:
In the backtraces above, there is one thread in the first location holding the buffers lock and trying to acquire the bind_groups lock, and one thread in the second location holding most locks (including the bind_group one) and trying to acquire the buffers lock. While these are all RWLocks, and these are all read lock acquisitions, there are also several threads trying to acquire write locks for both the bind_group and buffer storages. Due to the fair RWLock implementation in parking_lot, this makes the attempts to acquire read locks block until the write lock can be acquired, which then completes the deadlock. It sounds like |
Description
Might be a duplicate of one of the known deadlock issues in #5572, I'm not sure yet.
Repro steps
Closed source project, so not available.
Expected vs observed behavior
No deadlock vs Yes deadlock
Platform
Linux, Vulkan. wgpu 0.20.0 is affected (and is where the backtraces are from), but trunk also deadlocks in a similar way.
The text was updated successfully, but these errors were encountered: