Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: deadlock while typechecking self-referential constraint #49439

Closed
aarzilli opened this issue Nov 8, 2021 · 6 comments
Closed

cmd/compile: deadlock while typechecking self-referential constraint #49439

aarzilli opened this issue Nov 8, 2021 · 6 comments
Labels
NeedsInvestigation release-blocker
Milestone

Comments

@aarzilli
Copy link
Contributor

@aarzilli aarzilli commented Nov 8, 2021

Compiling this (wrong) code:

package main

type X[T any, PT X[T]] interface{}

causes a deadlock (I think it's trying to infer the second parameter):

fatal error: all goroutines are asleep - deadlock!

goroutine 1 [semacquire]:
sync.runtime_SemacquireMutex(0x0?, 0xe8?, 0x29?)
	/usr/local/go/src/runtime/sema.go:71 +0x25
sync.(*Mutex).lockSlow(0xc0004140f4)
	/usr/local/go/src/sync/mutex.go:153 +0x165
sync.(*Mutex).Lock(...)
	/usr/local/go/src/sync/mutex.go:81
sync.(*Once).doSlow(0x200?, 0xc00037cb98?)
	/usr/local/go/src/sync/once.go:64 +0x53
sync.(*Once).Do(...)
	/usr/local/go/src/sync/once.go:59
cmd/compile/internal/types2.(*Named).resolve(0xc000414080?, 0x9e?)
	/usr/local/go/src/cmd/compile/internal/types2/named.go:44 +0x5d
cmd/compile/internal/types2.asNamed(...)
	/usr/local/go/src/cmd/compile/internal/types2/type.go:74
cmd/compile/internal/types2.under({0xe85550?, 0xc000414080?})
	/usr/local/go/src/cmd/compile/internal/types2/type.go:24 +0x56
cmd/compile/internal/types2.(*TypeParam).iface(0xc000400450)
	/usr/local/go/src/cmd/compile/internal/types2/typeparam.go:84 +0x37
cmd/compile/internal/types2.(*TypeParam).underIs(0xe85640?, 0xc000400450?)
	/usr/local/go/src/cmd/compile/internal/types2/typeparam.go:138 +0x1e
cmd/compile/internal/types2.underIs({0xe85640?, 0xc000400450?}, 0xc00037ccd0)
	/usr/local/go/src/cmd/compile/internal/types2/expr.go:165 +0x52
...
@ALTree ALTree added this to the Go1.18 milestone Nov 8, 2021
@ALTree ALTree added NeedsInvestigation release-blocker labels Nov 8, 2021
@cuonglm
Copy link
Member

@cuonglm cuonglm commented Nov 8, 2021

This trybot failure seems a variant of this issue: https://storage.googleapis.com/go-build-log/09876462/linux-amd64-unified_f935df09.log

@findleyr findleyr self-assigned this Nov 8, 2021
@findleyr
Copy link
Contributor

@findleyr findleyr commented Nov 8, 2021

This doesn't appear to be fixed by the revert of CL 362254.

I'm investigating.

@findleyr
Copy link
Contributor

@findleyr findleyr commented Nov 8, 2021

This is a consequence of https://golang.org/cl/356489, which allowed inferring type instances and introduced a vector for recursive expansion.

I'll fix this instance, and will add a more general mechanism for detecting recursive expansion.

@gopherbot
Copy link

@gopherbot gopherbot commented Nov 9, 2021

Change https://golang.org/cl/361922 mentions this issue: cmd/compile/internal/types2: disallow type cycles through type parameter lists

@griesemer
Copy link
Contributor

@griesemer griesemer commented Nov 9, 2021

CL 361922 is a bit of a hammer, but it seems that uniform type inference is more important than type parameter lists that recurse with types to which those type parameter lists belong.

@gopherbot
Copy link

@gopherbot gopherbot commented Feb 18, 2022

Change https://go.dev/cl/386718 mentions this issue: go/types: refine the check for invalid cycles through tparam lists

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation release-blocker
Projects
None yet
Development

No branches or pull requests

6 participants