x/tools/gopls: frob.Decode panics with "surplus bytes" error

[gopherbot]

#!watchflakes
default <- pkg ~ `gopls` && output ~ `panic: surplus bytes` && output ~ `\(\*frob\)\.Decode`

Issue created automatically to collect these failures.

Example (log):

=== RUN   TestDefinition
=== PAUSE TestDefinition
=== CONT  TestDefinition
    integration_test.go:291: gopls definition a.go:7:2: exited with code 2, want success: true (gopls definition a.go:7:2: exit=2 stdout=<<./a.go:3:6-7: defined here as func f()
        >> stderr=<<panic: surplus bytes
        
        goroutine 1404 [running]:
        golang.org/x/tools/gopls/internal/util/frob.(*frob).Decode(0x5e9d31dcf200, {0x5e9d3d0e9c00, 0x8, 0x200}, {0x101845428?, 0x5e9d3c367420?})
        	/Users/swarming/.swarming/w/ir/x/w/targetrepo2751927001/gopls/internal/util/frob/frob.go:252 +0x18c
        golang.org/x/tools/gopls/internal/util/frob.Codec[...].Decode(...)
...
        golang.org/x/tools/gopls/internal/cache.(*analysisNode).runCached(0x1450f89b2000, {0x105ff2a98, 0x1450f89862d0}, {0xe2, 0x37, 0x30, 0x23, 0x4a, 0xd, 0x79, ...})
        	/Users/swarming/.swarming/w/ir/x/w/targetrepo2751927001/gopls/internal/cache/analysis.go:582 +0x1d8
        golang.org/x/tools/gopls/internal/cache.(*Snapshot).Analyze.func6.1()
        	/Users/swarming/.swarming/w/ir/x/w/targetrepo2751927001/gopls/internal/cache/analysis.go:340 +0x3d0
        golang.org/x/sync/errgroup.(*Group).Go.func1()
        	/Users/swarming/.swarming/w/ir/x/w/gopath/pkg/mod/golang.org/x/sync@v0.20.0/errgroup/errgroup.go:93 +0x4c
        created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 1128
        	/Users/swarming/.swarming/w/ir/x/w/gopath/pkg/mod/golang.org/x/sync@v0.20.0/errgroup/errgroup.go:78 +0x94
        >>)
--- FAIL: TestDefinition (3.94s)

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
default <- pkg == "golang.org/x/tools/gopls/internal/cmd" && test == "TestDefinition"

2026-04-09 22:36 x_tools-gotip-darwin-arm64-longtest tools@a2402e74 go@76ddc5b9 x/tools/gopls/internal/cmd.TestDefinition (log)

=== RUN   TestDefinition
=== PAUSE TestDefinition
=== CONT  TestDefinition
    integration_test.go:291: gopls definition a.go:7:2: exited with code 2, want success: true (gopls definition a.go:7:2: exit=2 stdout=<<./a.go:3:6-7: defined here as func f()
        >> stderr=<<panic: surplus bytes
        
        goroutine 1404 [running]:
        golang.org/x/tools/gopls/internal/util/frob.(*frob).Decode(0x5e9d31dcf200, {0x5e9d3d0e9c00, 0x8, 0x200}, {0x101845428?, 0x5e9d3c367420?})
        	/Users/swarming/.swarming/w/ir/x/w/targetrepo2751927001/gopls/internal/util/frob/frob.go:252 +0x18c
        golang.org/x/tools/gopls/internal/util/frob.Codec[...].Decode(...)
...
        golang.org/x/tools/gopls/internal/cache.(*analysisNode).runCached(0x1450f89b2000, {0x105ff2a98, 0x1450f89862d0}, {0xe2, 0x37, 0x30, 0x23, 0x4a, 0xd, 0x79, ...})
        	/Users/swarming/.swarming/w/ir/x/w/targetrepo2751927001/gopls/internal/cache/analysis.go:582 +0x1d8
        golang.org/x/tools/gopls/internal/cache.(*Snapshot).Analyze.func6.1()
        	/Users/swarming/.swarming/w/ir/x/w/targetrepo2751927001/gopls/internal/cache/analysis.go:340 +0x3d0
        golang.org/x/sync/errgroup.(*Group).Go.func1()
        	/Users/swarming/.swarming/w/ir/x/w/gopath/pkg/mod/golang.org/x/sync@v0.20.0/errgroup/errgroup.go:93 +0x4c
        created by golang.org/x/sync/errgroup.(*Group).Go in goroutine 1128
        	/Users/swarming/.swarming/w/ir/x/w/gopath/pkg/mod/golang.org/x/sync@v0.20.0/errgroup/errgroup.go:78 +0x94
        >>)
--- FAIL: TestDefinition (3.94s)

— watchflakes

[adonovan]

@findleyr Regression in https://go.dev/cl/763240? (I have no idea how, but this code has never once failed before we touched it this week.)

[findleyr]

@adonovan I don't see how... we didn't touch analysis in that PR (apart from the filecache.Bytes passthrough).

Also, Claude points out that this is frob.Decode on 8 bytes (len=8, cap=512), which is probably coming from os.ReadFile (512 is the min cap, apparently). So probably not even related to the memcache?

...but of course, the timing IS suspicious. Let's perhaps wait and see...

[findleyr]

This is not a regression: #76104

Also, the fact that this failed across #78618/#78619/#78620 (one build, multiple processes on the same builder) suggests that it's a disk issue, not related to the memory cache.

[adonovan]

Thanks for investigating. I can believe this is a memory error: they are a lot more common than I previously thought.

Wouldn't it be nice if consumer hardware came with ECC memory? But apparently none of the manufacturers dare produce such a thing as it would eat away at the lucrative server-class market segment.

[adonovan]

Having said that, a disk error wouldn't explain it (nor would a memory error that corrupted what was written to the disk) because the filecache does a consistency check after loading. So three processes failing at the same time on the same machine doesn't seem likely to be either a RAM issue or incorrect disk bytes.