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
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Milestone

Comments

@aarzilli
Copy link
Contributor

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 Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker labels Nov 8, 2021
@cuonglm
Copy link
Member

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 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 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

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

@griesemer
Copy link
Contributor

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

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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. release-blocker
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants