You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was writing a simple Unix socket HTTP + WebSocket proxy when I stumbled upon this issue. Roughly 1/3 of the times the server gets stuck when upgrading the connection to WebSocket. The culprit seems to be Hijack(), which attempts to abortPendingRead() but the background read goroutine doesn't seem to receive the signal and therefore deadlocks.
Run the client over and over until the server deadlocks (on my machine this happens at least once every 5 tries)
Although the sample code uses gorilla websockets, the issue doesn't seem related to it. To demonstrate it I additionally wrote a basic websocket implementation that you can trigger on the server by adding the --no-gorilla command line argument.
What did you see happen?
This is a Goroutine dump from when the issue occurs on the server. Observe how the hijacking goroutine gets stuck in abortPendingRead, while the backgroundRead goroutine remains stuck on the read syscall.
This looks similar to #19747, but it's not the same issue since my system time is up to date.
Go version
go version go1.23.1 linux/amd64
Output of
go env
in your module/workspace:What did you do?
I was writing a simple Unix socket HTTP + WebSocket proxy when I stumbled upon this issue. Roughly 1/3 of the times the server gets stuck when upgrading the connection to WebSocket. The culprit seems to be Hijack(), which attempts to
abortPendingRead()
but the background read goroutine doesn't seem to receive the signal and therefore deadlocks.I wrote a reproducer here, the steps to reproduce are in the README: https://github.com/depau/golang-unix-websocket-deadlock
In short:
Although the sample code uses gorilla websockets, the issue doesn't seem related to it. To demonstrate it I additionally wrote a basic websocket implementation that you can trigger on the server by adding the
--no-gorilla
command line argument.What did you see happen?
This is a Goroutine dump from when the issue occurs on the server. Observe how the hijacking goroutine gets stuck in
abortPendingRead
, while thebackgroundRead
goroutine remains stuck on the read syscall.This looks similar to #19747, but it's not the same issue since my system time is up to date.
What did you expect to see?
I expected it to not deadlock :)
The text was updated successfully, but these errors were encountered: