-
Notifications
You must be signed in to change notification settings - Fork 304
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
Deadlocks due to CloseRead #429
Comments
Copy. Will rework the close code ASAP. See also #427 |
Actually can you provide a trace? CloseRead done's the wait group before it closes. https://github.com/nhooyr/websocket/blob/e3a2d32f704fb06c439e56d2a85334de04b50d32/read.go#L69 But I will concede the use of a wait group in this way is certainly potentially panicky as the |
@nhooyr the problem is that |
Oh I'm blind great point! Confirmed. 🤦🏼 |
Thanks for reporting. I've fixed this in #427. Please review and let me know if you see anything else. |
Sorry for the delay. Fixed by #427. |
nhooyr.io/websocket v1.8.10
The library uses defer
defer wg.Wait()
in multiple functions and that causes calls to deadlock instead of properly shutting down when connection is terminated.One possible situation is this:
CloseRead
CloseRead
unblocks fromReader(ctx)
and callsClose
Close
blocks ondefer c.wg.Wait()
but it can't succeed due toCloseRead
callingwg.Add(1)
and expecting it to be decremented withdefer wg.Done()
on exit fromCloseRead
. ButCloseRead
cannot exit due toClose
blocking. We have a deadlock and a goroutine leak. Context is never cancelled either which means all the other code that interacts with websocket also can't properly exit.Switching to manually calling
Read
in a separate goroutine and cancelling context from it solves this problem. Basically, you have to reimplementCloseRead
but without blocking on waitGroupThe text was updated successfully, but these errors were encountered: