x/net/http2: id(*) < evictCount(*) panic

[zkcrescent]

Go version

go1.23.3

Output of go env in your module/workspace:

GO111MODULE='on'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/wangbailu/Library/Caches/go-build'
GOENV='/Users/wangbailu/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/wangbailu/go/pkg/mod'
GONOPROXY='gitlab.hypergryph.net'
GONOSUMDB='gitlab.hypergryph.net'
GOOS='darwin'
GOPATH='/Users/wangbailu/go'
GOPRIVATE='gitlab.hypergryph.net'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.23.3'
GODEBUG=''
GOTELEMETRY='local'
GOTELEMETRYDIR='/Users/wangbailu/Library/Application Support/go/telemetry'
GCCGO='gccgo'
GOARM64='v8.0'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/wangbailu/go/src/gitlab.hypergryph.net/web/golang/url-shortener/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/xv/_533xxcx35jf59f06099m5sdqd8mcg/T/go-build2936925539=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

panic: id (944) <= evictCount (946)

goroutine 2004 [running]:
vendor/[golang.org/x/net/http2/hpack.(*headerFieldTable).idToIndex](http://golang.org/x/net/http2/hpack.(*headerFieldTable).idToIndex)(0xc000056100, 0xc000e9b110?)
	/usr/local/go/src/vendor/[golang.org/x/net/http2/hpack/tables.go:118](http://golang.org/x/net/http2/hpack/tables.go:118) +0xbd
vendor/[golang.org/x/net/http2/hpack.(*headerFieldTable).search](http://golang.org/x/net/http2/hpack.(*headerFieldTable).search)(0xc000056100, {{0xc00026ea50, 0xd}, {0xc0001a9620, 0x20}, 0x0})
	/usr/local/go/src/vendor/[golang.org/x/net/http2/hpack/tables.go:105](http://golang.org/x/net/http2/hpack/tables.go:105) +0xe5
vendor/[golang.org/x/net/http2/hpack.(*Encoder).searchTable](http://golang.org/x/net/http2/hpack.(*Encoder).searchTable)(0xc000056100, {{0xc00026ea50, 0xd}, {0xc0001a9620, 0x20}, 0x0})
	/usr/local/go/src/vendor/[golang.org/x/net/http2/hpack/encode.go:97](http://golang.org/x/net/http2/hpack/encode.go:97) +0x85
vendor/[golang.org/x/net/http2/hpack.(*Encoder).WriteField](http://golang.org/x/net/http2/hpack.(*Encoder).WriteField)(0xc000056100, {{0xc00026ea50, 0xd}, {0xc0001a9620, 0x20}, 0x0})
	/usr/local/go/src/vendor/[golang.org/x/net/http2/hpack/encode.go:62](http://golang.org/x/net/http2/hpack/encode.go:62) +0x145
net/http.(*http2ClientConn).writeHeader(0xc00026ea40?, {0xc00026ea50?, 0xffffffffffffffff?}, {0xc0001a9620?, 0xc0007067e0?})
	/usr/local/go/src/net/http/h2_bundle.go:9331 +0x148
net/http.(*http2ClientConn).encodeHeaders.func3({0xc00026ea40?, 0xc0007067e0?}, {0xc0001a9620, 0x20})
	/usr/local/go/src/net/http/h2_bundle.go:9265 +0x71
net/http.(*http2ClientConn).encodeHeaders.func1(0xc0007fcbb8)
	/usr/local/go/src/net/http/h2_bundle.go:9226 +0x627
net/http.(*http2ClientConn).encodeHeaders(0xc0003c4300, 0xc000704f00, 0x1, {0x0, 0x0}, 0x40)
	/usr/local/go/src/net/http/h2_bundle.go:9258 +0x58c
net/http.(*http2clientStream).encodeAndWriteHeaders(0xc0004e5500, 0xc000704f00)
	/usr/local/go/src/net/http/h2_bundle.go:8721 +0x2e9
net/http.(*http2clientStream).writeRequest(0xc0004e5500, 0xc000704f00, 0x0)
	/usr/local/go/src/net/http/h2_bundle.go:8617 +0x535
net/http.(*http2clientStream).doRequest(0xc0004e5500, 0x1a52b10?, 0xc0000e9110?)
	/usr/local/go/src/net/http/h2_bundle.go:8551 +0x56
created by net/http.(*http2ClientConn).roundTrip in goroutine 562
	/usr/local/go/src/net/http/h2_bundle.go:8456 +0x3d8

I've met upper panic when I use fiber web framwork , it's based on fasthttp, and I've found related issue . By some self-check, I find out that this panic point to golang.org/x/net/http2 package. and there are some related issue 69316 43051 in current repo but neither fixed.

this phenomenon could happed in different browsers(firefox, chrome), and could be solved by disable http2 when building with -tags nethttpomithttp2

What did you see happen?

Panic.

What did you expect to see?

running correctly.

[zkcrescent]

BTW, this happened on both mac and linux.

[gabyhelp]

Related Issues

• x/net/http2/hpack: "id (106) <= evictCount (117)" panic in headerFieldTable.idToIndex #69316
• x/net/http2: hpack.(*Encoder).WriteField panic errors #47882 (closed)
• x/net/http2/h2c panic #67168 (closed)
• when use standard http client panic id (14) <= evictCount (14) #43048 (closed)
• x/net/http2: standard http client panics listing an evictCount #43051 (closed)
• panic: id <= evictCount on mp-quic #65797 (closed)
• x/net/http2: closeStream has panic #59601 (closed)
• net/http: http2 round tripper nil pointer dereference causes panic causing deadlock #65927 (closed)
• x/net/http2: panic: interface conversion: http.http2Frame is *http.http2UnknownFrame, not *http.http2HeadersFrame #31986
• affected/package: sync #53769 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[ianlancetaylor]

CC @neild

[cherrymui]

Thanks for the report. Could you provide a way to reproduce the failure? Would be nice if you could have a way to reproduce directly with net/http and golang.org/x/net/http2 packages. Thanks.

[zkcrescent]

I'm sorry I can't provide the original code due to company security regulations. I create a simple web app by fiber with only CURD apis, and I run it on my MAC. And then I trigger quick access to an API through a button on CHROME (rapidly clicking the button to activate it). Sometimes it can be reproduced in about ten attempts, while other times it requires rapid consecutive clicking for half a minute, but finally could be reproduced.

I also use ab(apache benchmark) tool and a golang test case to pressure test this API , even the concurrency to 50, this failure could not be reproduced.

I believe the error might be caused by the re-establishment of connections. In my test cases, under high concurrency, connections might be continuously reused without being re-established, whereas requests on Chrome might involve re-establishment (this is just my speculation).

[zkcrescent]

@cherrymui Do you have any clues yet? Is there any other information I can provide here?

[neild]

Without a reproduction case, I'm not certain how much progress we can make here.

I've examined the code, and I don't see how this can happen. I believe that it is happening, so I'm probably missing something, but I haven't been able to see it. I've tried writing various tests and fuzzers, and none of them produce this error.

I think we need a program we can run that reproduces the failure to make any progress.