x/tools/gopls: nil (or invalid) *ExprStmt pointer in AST

[adonovan]

#!stacks
"sigpanic" && "unusedresult.run.func1:+1"

Issue created by stacks.

func run(pass *analysis.Pass) (any, error) {
...
	inspect.Preorder(nodeFilter, func(n ast.Node) {
		call, ok := ast.Unparen(n.(*ast.ExprStmt).X).(*ast.CallExpr) // panics loading .X field

TEXT golang.org/x/tools/go/analysis/passes/unusedresult.run.func1(SB) go/analysis/passes/unusedresult/unusedresult.go
...
  unusedresult.go:142   0x9a9f8f                55                      PUSHQ BP                                                                                                                      
  unusedresult.go:142   0x9a9f90                4889e5                  MOVQ SP, BP                                                                                                                   
  unusedresult.go:142   0x9a9f93                4881ecd8000000          SUBQ $0xd8, SP                                                                                                                
  unusedresult.go:142   0x9a9f9a                48898424e8000000        MOVQ AX, 0xe8(SP)                                                                                                             
  unusedresult.go:142   0x9a9fa2                48899c24f0000000        MOVQ BX, 0xf0(SP)                                                                                                             
  unusedresult.go:142   0x9a9faa                488b7210                MOVQ 0x10(DX), SI                                                                                                             
  unusedresult.go:143   0x9a9fae                488d3d8b7ac700          LEAQ go:itab.*go/ast.ExprStmt,go/ast.Node(SB), DI                                                                             
  unusedresult.go:143   0x9a9fb5                4839f8                  CMPQ AX, DI                                                                                                                   
  unusedresult.go:143   0x9a9fb8                0f856d030000            JNE 0x9aa32b                                                                                                                  
  unusedresult.go:143   0x9a9fbe                488b0b                  MOVQ 0(BX), CX            // SEGV loading first word of ExprStmt.X
  unusedresult.go:143   0x9a9fc1                488b7b08                MOVQ 0x8(BX), DI                                                                                                              

If the ExprStmt pointer is nil, that means the parser has a bug or the AST has become corrupted. If it is non-nil, then we have memory corruption.

This stack NVOHJQ was reported by telemetry:

• crash/crash
• runtime.throw:+9,+0x47
• runtime.sigpanic:+33,+0x26b
• golang.org/x/tools/go/analysis/passes/unusedresult.run.func1:+1,+0x3e
• golang.org/x/tools/go/ast/inspector.(*Inspector).Preorder:+20,+0x90
• golang.org/x/tools/go/analysis/passes/unusedresult.run:+14,+0x233
• golang.org/x/tools/gopls/internal/cache.(*action).exec.func6:+31,+0x96
• golang.org/x/tools/gopls/internal/cache.(*action).exec:+199,+0xab8
• golang.org/x/tools/gopls/internal/cache.execActions.func1.1:+2,+0x51
• sync.(*Once).doSlow:+5,+0xab
• sync.(*Once).Do:=69,+0x84
• golang.org/x/tools/gopls/internal/cache.execActions.func1:+2,+0x4e
• runtime.goexit:+0,+0x0

golang.org/x/tools/gopls@v0.20.0 go1.25.2 linux/amd64 gopls.client=vscode (1)

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

[linsite]

Just a thought. Is it possible (or appropriate) for telemetry to collect whether ECC memory is present?

[adonovan]

Just a thought. Is it possible (or appropriate) for telemetry to collect whether ECC memory is present?

That would be interesting, but on Linux it generally requires root capability to ask such questions, and on the hardware underneath macOS the answer is always no.

[linsite]

Just a thought. Is it possible (or appropriate) for telemetry to collect whether ECC memory is present?

That would be interesting, but on Linux it generally requires root capability to ask such questions, and on the hardware underneath macOS the answer is always no.

Oh, I overlooked the “root capability” requirement. My apologies.