-
Notifications
You must be signed in to change notification settings - Fork 91
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
cmd/acme: more deadlocks #85
Comments
lock currently held by goroutine 30; xfideventread
|
This one happened very soon after startup.
|
I added some instrumentation to all uses of sync.Mutex that records some stack information about acquirer:
|
Looks like the issue is that there's an ordering requirement that the window lock should be "inside" biglock, but because Seems like this is a potential problem anywhere we bigUnlock while holding some other lock. |
I'm reverting 6faf3d8 in my copy for the time being because it's not easy to drop the window lock from inside Textselect. |
Here's another one - it's not OK for
|
Another one, very similar, but different entry point into
|
Making a new issue for deadlocks found after the recent fixes.
I've also instrumented my version to report which goroutine id held the deadlock and where it was acquired.
The text was updated successfully, but these errors were encountered: