runtime: spurious SEGV in package initializer (darwin/amd64)

[gopherbot]

#!watchflakes
default <- pkg == "golang.org/x/tools/go/analysis/passes/loopclosure" && test == ""

Issue created automatically to collect these failures.

Example (log):

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x50 pc=0x4d0537d]

goroutine 1 [running]:
go/types.init.2()
	/Users/swarming/.swarming/w/ir/x/w/goroot/src/go/types/universe.go:282 +0x1dd
FAIL	golang.org/x/tools/go/analysis/passes/loopclosure	0.030s

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
default <- pkg == "golang.org/x/tools/go/analysis/passes/loopclosure" && test == ""

2025-01-27 04:28 x_tools-go1.24-darwin-amd64_14 tools@edafbe5d release-branch.go1.24@8a4c24f9 x/tools/go/analysis/passes/loopclosure (log)

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x50 pc=0x4d0537d]

goroutine 1 [running]:
go/types.init.2()
	/Users/swarming/.swarming/w/ir/x/w/goroot/src/go/types/universe.go:282 +0x1dd
FAIL	golang.org/x/tools/go/analysis/passes/loopclosure	0.030s

— watchflakes

[adonovan]

Building the same text with the same toolchain, stack shows only this line in the package initializer for go/types:

  universe.go:282       0x1227373               b904000000              MOVL $0x4, CX                                       
  universe.go:282       0x1227378               e82307feff              CALL go/types.(*Scope).Lookup(SB)                       
  universe.go:282       0x122737d               488b5050                MOVQ 0x50(AX), DX    <--- return pc here                                          

Not sure what conclusion to draw from the lack of a frame for Lookup in the backtrace.

In any case, this early-stage initializer failure looks like a compiler or runtime issue.

[cherrymui]

Not sure what conclusion to draw from the lack of a frame for Lookup in the backtrace.

It is probably that this is actually the fault PC, not a return PC. The faulting address is 0x50, and this instruction is loading from 0x50(AX), which suggests AX is 0, i.e. Lookup returns 0.