-
Notifications
You must be signed in to change notification settings - Fork 312
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
potential leak when write and tcp closed concurrently #405
Comments
Good catch! |
Open
nhooyr
added a commit
that referenced
this issue
Oct 19, 2023
Closes #405 You should always be reading from the connection with CloseRead so this shouldn't have affected anyone using the library correctly.
This shouldn't have affected anyone using the library correctly as you'd want to use |
Fixed in dev. |
This was referenced Nov 27, 2024
spikecurtis
added a commit
to coder/coder
that referenced
this issue
Dec 3, 2024
fixes #14881 Our handlers for streaming logs don't read from the websocket. We don't allow the client to send us any data, but the websocket library we use requires reading from the websocket to properly handle pings and closing. Not doing so can [can cause the websocket to hang on write](coder/websocket#405), leaking go routines which were noticed in #14881. This fixes the issue, and in process refactors our log streaming to a encoder/decoder package which provides generic types for sending JSON over websocket. I'd also like for us to upgrade to the latest https://github.com/coder/websocket but we should also upgrade our tailscale fork before doing so to avoid including two copies of the websocket library.
stirby
pushed a commit
to coder/coder
that referenced
this issue
Dec 3, 2024
fixes #14881 Our handlers for streaming logs don't read from the websocket. We don't allow the client to send us any data, but the websocket library we use requires reading from the websocket to properly handle pings and closing. Not doing so can [can cause the websocket to hang on write](coder/websocket#405), leaking go routines which were noticed in #14881. This fixes the issue, and in process refactors our log streaming to a encoder/decoder package which provides generic types for sending JSON over websocket. I'd also like for us to upgrade to the latest https://github.com/coder/websocket but we should also upgrade our tailscale fork before doing so to avoid including two copies of the websocket library. (cherry picked from commit 148a5a3)
stirby
pushed a commit
to coder/coder
that referenced
this issue
Dec 11, 2024
fixes #14881 Our handlers for streaming logs don't read from the websocket. We don't allow the client to send us any data, but the websocket library we use requires reading from the websocket to properly handle pings and closing. Not doing so can [can cause the websocket to hang on write](coder/websocket#405), leaking go routines which were noticed in #14881. This fixes the issue, and in process refactors our log streaming to a encoder/decoder package which provides generic types for sending JSON over websocket. I'd also like for us to upgrade to the latest https://github.com/coder/websocket but we should also upgrade our tailscale fork before doing so to avoid including two copies of the websocket library. (cherry picked from commit 148a5a3)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
if client close tcp connection directly when server write data with background context.
the goroutine do
Write
may block forever, and succeedWrite
may block too.Solution
DO NOT call
Write
method withcontext.Background
,AND DO
Read
in goroutine once connection established.analysis
in
Conn.writeFrame
if real write to tcp failed.in defer func, it wait
closed
orcontext.Done
.if there is no read goroutine, no
closed
eventfirst stucked write stack may like
succeed stack may like
reproduce code
The text was updated successfully, but these errors were encountered: