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

Jump to bottom

go/types: race condition due to lazy initialization of universeError #47345

Closed
mdempsky opened this issue Jul 22, 2021 · 5 comments
Closed

go/types: race condition due to lazy initialization of universeError #47345

mdempsky opened this issue Jul 22, 2021 · 5 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.18

Comments

@mdempsky
Copy link
Member

This program triggers a race condition in go/types on dev.typeparams since 24f9eb2:

package main

import (
	"go/types"
	"sync"
)

func main() {
	var wg sync.WaitGroup

	for i := 0; i < 2; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			types.Universe.Lookup("error").Type().Underlying().(*types.Interface).NumMethods()
		}()
	}

	wg.Wait()
}

/cc @findleyr @griesemer
@mdempsky mdempsky added the NeedsFix The path to resolution is known, but the work has not been done. label Jul 22, 2021
@mdempsky mdempsky added this to the Go1.18 milestone Jul 22, 2021
@findleyr
Copy link
Contributor

@mdempsky thanks for that repro!

This is because we lazily write the interface type set. We should eagerly add an empty type set for interfaces in the universe.

@gopherbot
Copy link

Change https://golang.org/cl/336910 mentions this issue: [dev.typeparams] go/types, types2: set tset when constructing interfaces in the universe

gopherbot pushed a commit that referenced this issue Jul 24, 2021
@findleyr
[dev.typeparams] go/types, types2: set tset when constructing interfa…
9f928f9 
…ces in the universe

As of CL 334894, type sets are lazily evaluated on interfaces. For the
universe interfaces error and comparable, this can lead to data races
when type checking concurrently. Fix this by computing their type set
when they are defined.

Tested using the repro from #47345. I considered checking this in as a
test, but it probably wouldn't add much value going forward.

Fixes #47345

Change-Id: I014a511b8e3c092c86201a8bfc7f5f494f8f20e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/336910
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
@findleyr
Copy link
Contributor

It seems that gopherbot did not find the 'fixes' line on the previous CL, because it was not the first mention of this issue? In any case, closing as fixed.

@zikaeroh
Copy link
Contributor

FWIW, gopherbot did, but GitHub won't close issues via commits until those commits are merged back to the main branch of the repo (so for dev. branches you have to wait or close manually).

@findleyr
Copy link
Contributor

@zikaeroh that makes sense, thanks for the explanation!

@findleyr findleyr mentioned this issue Aug 16, 2021
Closed
@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
4 participants
@mdempsky @gopherbot @zikaeroh @findleyr