x/tools/gopls: SEGV due to invalid g in brand new goroutine

[adonovan]

#!stacks
"crash/crash" && "cache.(*parseCache).gc:+0"

Issue created by stacks.

Well this is an interesting one: we have a brand new goroutine that has executed one stack check and one preemption check, and yet its its R28 (g) is corrupt by the time of the second stack check.

TEXT golang.org/x/tools/gopls/internal/cache.(*parseCache).gc(SB) golang.org/x/tools/gopls@v0.20.0/internal/cache/parse_cache.go
  parse_cache.go:256    0x10081fbe0             f9400b90                MOVD 16(R28), R16                 <--- SEGV
...

TEXT golang.org/x/tools/gopls/internal/cache.newParseCache.gowrap1(SB) golang.org/x/tools/gopls@v0.20.0/internal/cache/parse_cache.go
  parse_cache.go:119    0x10081ef30             f9400b90                MOVD 16(R28), R16          // load g.stackguard0                                             
  parse_cache.go:119    0x10081ef34             eb3063ff                CMP R16, RSP                     // check overflow
  parse_cache.go:119    0x10081ef38             54000169                BLS 11(PC)                         // handle it                        
stackok:
  parse_cache.go:119    0x10081ef3c             f81e0ffe                MOVD.W R30, -32(RSP)        // save LR (R30)
  parse_cache.go:119    0x10081ef40             f81f83fd                MOVD R29, -8(RSP)              // save FP (R29)                                         
  parse_cache.go:119    0x10081ef44             d10023fd                SUB $8, RSP, R29                // displace the stack                                        
  parse_cache.go:119    0x10081ef48             f9401390                MOVD 32(R28), R16           //  load g._panic                                      
  parse_cache.go:119    0x10081ef4c             b5000130                CBNZ R16, 9(PC)                //  handle it   
nopanic:                                      
  parse_cache.go:119    0x10081ef50             f9400740                MOVD 8(R26), R0               // load c                                          
  parse_cache.go:119    0x10081ef54             94000323                CALL golang.org/x/tools/gopls/internal/cache.(*parseCache).gc(SB)       
  parse_cache.go:119    0x10081ef58             f85f83fd                MOVD -8(RSP), R29                <---- PC+1 is here                                       
...

This means something has corrupted R28 between the two stack checks. The only code that has run in this thread are the checks themselves. I think this implies only one of three possibilities:

1. the runtime stack check corrupted R28.
2. async preemption corrupted R28.
3. hardware fault (unlikely: this class of crash is too common across our fleet of 8000 telemetry-enabled machines).

Of course, both of 1 and 2 could be explained by corruption of runtime internal data structures by an errant mutator, but I think we can safely conclude that the runtime must be involved in this corruption.

This stack 6__P9g was reported by telemetry:

• crash/crash
• golang.org/x/tools/gopls/internal/cache.(*parseCache).gc:+0,+0x0
• golang.org/x/tools/gopls/internal/cache.newParseCache.gowrap1:+0,+0x27
• runtime.goexit:+0,+0x3

golang.org/x/tools/gopls@v0.20.0 go1.25.4 darwin/arm64 gopls.client=vscode (2)

Use this command to reproduce the executable:
(HOME=$(mktemp -d); GOOS=darwin GOARCH=arm64 GOTOOLCHAIN=go1.25.4 go install golang.org/x/tools/gopls@v0.20.0 && find $HOME/go/bin -type f)
To disassemble: go tool objdump exe | less

[prattmic]

4. the OS corrupted R28.

(IMO should be listed if we're going to list hardware)

[gabyhelp]

Related Issues

• x/tools/gopls: SEGV accessing g in function prolog (R28 is nil or invalid) #76158
• x/tools/gopls: DidChangeWatchedFiles: impossible crash in growslice #75465
• x/tools/gopls: SEGV in prolog of metadata.Graph.Update (bad g or sp) #74256
• x/tools/gopls: SEGV due to nil or invalid g in sa4011.run #76644
• x/tools/gopls: gcStart crashes while calling finishsweep_m on system stack #75691
• x/tools/gopls: impossible crash in strings.HasPrefix #76627
• x/tools/gopls: SEGV in string comparison in mapaccess #76159
• x/tools/gopls: SEGV in gcimporter.iexportCommon (bad SP) #72135
• x/tools/gopls: corrupt g in printf.run #75232
• x/tools/gopls: crash in bgsweep #73262

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