Go version
go1.25.10
Output of go env in your module/workspace:
set AR=ar
set CC=gcc
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_ENABLED=0
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set CXX=g++
set GCCGO=gccgo
set GO111MODULE=
set GOAMD64=v1
set GOARCH=amd64
set GOAUTH=netrc
set GOBIN=
set GOCACHE=C:\Users\ticchioned\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=
set GOENV=C:\Users\ticchioned\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-m64 -fno-caret-diagnostics -Qunused-arguments -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\TICCHI~1\AppData\Local\Temp\2\go-build571379551=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=NUL
set GOMODCACHE=C:\Users\ticchioned\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\ticchioned\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTELEMETRY=local
set GOTELEMETRYDIR=C:\Users\ticchioned\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.26.5
set GOWORK=
set PKG_CONFIG=pkg-config
What did you do?
Long-running server process (InfluxDB 2.9.1, built with -ldflags "-s -w"). The workload creates a large number of independent 1-second time.Ticker goroutines — approximately 1,445 subsystems each running two tickers, so ~2,900 timer operations per second — plus heavy channel traffic and ~284 GB of memory-mapped file sections (~13,300 mapped regions). Go heap is modest at ~7.4 GB committed.
What did you see happen?
The process deadlocks completely and permanently, roughly every 1–5 weeks (observed at 9 and 13 days of uptime). Symptoms:
- 0% CPU, indefinitely
- Process alive; the OS still completes
accept() on the listening socket, but no HTTP handler ever runs — every request times out client-side
/debug/pprof/goroutine hangs forever. It works normally when the process is healthy.- No log output at all (logging allocates)
- No panic, no
fatal error, no runtime: out of memory
- Never self-recovers; requires killing the process
- The OS itself is unaffected — other processes on the same machine continue normally, including disk-active ones
What did you expect to see?
Normal operation, or at minimum a diagnosable failure.
Go version
go1.25.10
Output of
go envin your module/workspace:What did you do?
Long-running server process (InfluxDB 2.9.1, built with
-ldflags "-s -w"). The workload creates a large number of independent 1-secondtime.Tickergoroutines — approximately 1,445 subsystems each running two tickers, so ~2,900 timer operations per second — plus heavy channel traffic and ~284 GB of memory-mapped file sections (~13,300 mapped regions). Go heap is modest at ~7.4 GB committed.What did you see happen?
The process deadlocks completely and permanently, roughly every 1–5 weeks (observed at 9 and 13 days of uptime). Symptoms:
accept()on the listening socket, but no HTTP handler ever runs — every request times out client-side/debug/pprof/goroutinehangs forever. It works normally when the process is healthy.fatal error, noruntime: out of memoryWhat did you expect to see?
Normal operation, or at minimum a diagnosable failure.