go/types: stack overflow in Alignof

[adonovan]

#!stacks
"crash/crash" &&
 ("go/types.(*Named).resolve:+0" || "go/types.(*Named).Underlying:+0") &&
 "go/types.(*Named).under:+1" && 
 "go/types.(*gcSizes).Alignof:+7" &&
 "go/types.(*gcSizes).Alignof:+29"

Issue created by stacks.

Looks like Alignof was applied to a named struct type (illegally) containing itself as its first field.

This stack gYYnog was reported by telemetry:

• crash/crash
• go/types.(*Named).resolve:+0
• go/types.(*Named).Underlying:+2
• go/types.(*Named).under:+1
• go/types.under:+2
• go/types.(*gcSizes).Alignof:+7
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29

golang.org/x/tools/gopls@v0.17.1 go1.23.3 windows/amd64 vscode (1)

Dups: 2Xy8hA

[adonovan]

Hmm, the underlying type of the struct literal in type S struct { S } is invalid type, so the real question is how did the self-containing struct type get constructed?

[gabyhelp]

Related Issues

• go/types: panic("t.fromRHS = %s, typ = %s") in setDefType #71029
• x/tools/gopls: stack overflow with type parameters (built with go1.18beta1) #50881 (closed)
• cmd/go: compiler panic on recursive structures #45661 (closed)
• cmd/compile: bug in cmd/compile/internal/types.(*Type).Pos #71005
• go/types, types2: stack overflow results after naming type parameter after interface name. #50517 (closed)
• go/types, types2: infinite recursion if constraint type and type param have same name #50321 (closed)
• x/tools/gopls: Rename: crash due to Info.Defs[id]=nil bug in checkStructField #70968
• x/tools/gopls: OOM reported by fatal in runtime.mallocgc (windows) #70445 (closed)
• cmd/compile: panic if recursive type with field of error type #47636 (closed)
• go/types: infinite recursion in gopls via *TypeParam.Underlying #50803 (closed)

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

[adonovan]

This stack 2Xy8hA was reported by telemetry:

• crash/crash
• go/types.(*Named).Underlying:+0
• go/types.(*Named).under:+1
• go/types.under:+2
• go/types.(*gcSizes).Alignof:+7
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29
• go/types.(*gcSizes).Alignof:+29

golang.org/x/tools/gopls@v0.17.0 go1.23.5 darwin/arm64 other,vscode (2)