sync: Map: internal/sync.HashTrieMap: ran out of hash bits while inserting

[MasterDimmy]

Go version

go1.24.2 windows/amd64

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=1
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\1\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=
set GOENV=C:\Users\1\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=E:\TEMP\go-build1607997771=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=M:\Projects\AY\Trapper.System\pool_lines_provider\go.mod
set GOMODCACHE=D:\gopath\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=D:\gopath
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=D:\go
set GOSUMDB=sum.golang.org
set GOTELEMETRY=off
set GOTELEMETRYDIR=C:\Users\1\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=D:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.24.2
set GOWORK=
set PKG_CONFIG=pkg-config

What did you do?

var updatePoolLineUsage_keys sync.Map // key => ip
var key, ip string
...
updatePoolLineUsage_keys.Store(key, ip)

What did you see happen?

Panic in

internal/sync.HashTrieMap: ran out of hash bits while inserting
STACK:
goroutine 870014 [running]:
panic({0xfb2660?, 0x1434870?})
D:/go/src/runtime/panic.go:792 +0x132
internal/sync.(*HashTrieMap[...]).expand(0x14602c0?, 0xc003e8aba0, 0xc008401bc0, 0xa879ce25c8134d64, 0x0, 0xc004f668c0)
D:/go/src/internal/sync/hashtriemap.go:181 +0x1e5
internal/sync.(*HashTrieMap[...]).Swap(0x14602c0, {0xfb2660, 0xc0048a8950}, {0xfb2660, 0xc0048a8960})
D:/go/src/internal/sync/hashtriemap.go:272 +0x397
internal/sync.(*HashTrieMap[...]).Store(...)
D:/go/src/internal/sync/hashtriemap.go:200
sync.(*Map).Store(...)
D:/go/src/sync/hashtriemap.go:55

What did you expect to see?

ok

[gabyhelp]

Related Issues

• unique: "run out of hash bits" bug in internal HashTrieMap #69534 (closed)
• go1.3.3 hashmap bug #9335 (closed)
• internal/concurrent: unrecognized failures #66929
• sync: concurrent map iteration and map write on Map error #24112 (closed)
• runtime: panic: runtime error: hash of unhashable type [2]string #67608 (closed)
• internal/concurrent: hashtriemap uses abi.NoEscape cause incorrect inlining decision #68511 (closed)
• runtime: Invalid "concurrent map writes" after recovered runtime-panic on previous map assign with non-comparable key #19359 (closed)
• affected/package: sync #53769 (closed)
• cmd/go2go: panic in type checker #43526 (closed)

Related Discussions

• Crashing at runtime.sigpanic() during runtime.mapassign() in highly concurrent map writing situation?

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

[MasterDimmy]

This can help: this code reproduces bug every hour near 100% probability:

var (
 updatePoolLineUsage_tx sync.Once
 updatePoolLineUsage_keys sync.Map //key => ip
)

func updatePoolLineUsage(key, ip string) {
	defer handlePanic()

	updatePoolLineUsage_keys.Store(key, ip)

	updatePoolLineUsage_tx.Do(func() {
		go func() {
			defer handlePanic()

			ticker := time.NewTicker(time.Minute)
			for {
				select {
				case <-ticker.C:
					keys := []string{}
					updatePoolLineUsage_keys.Range(func(k, _ any) bool {
						keys = append(keys, k.(string))
						return true
					})

					for _, key := range keys {
                                               log(key)

						updatePoolLineUsage_keys.Delete(key)
					}
				}
			}
		}()
	})
}

No more usage updatePoolLineUsage_keys anywhere in code.
"key" is random of 16 or 64 bytes. There are near 100 active keys every hour.

[mknyszek]

Thanks for the report.

Can you please provide a more complete reproducer? How is updatePoolLineUsage invoked in your program? Are the arguments created with unsafe.String or unsafely in some way? Also, is there a way to get it to reproduce faster? (By removing the time.Ticker and just iterating in a loop?)