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

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
Assignees
Labels
Milestone

Comments

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Jul 22, 2021

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 this to the Go1.18 milestone Jul 22, 2021
@findleyr
Copy link
Contributor

@findleyr findleyr commented Jul 22, 2021

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

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Jul 23, 2021

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

Loading

gopherbot pushed a commit that referenced this issue Jul 24, 2021
…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

@findleyr findleyr commented Jul 26, 2021

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.

Loading

@findleyr findleyr closed this Jul 26, 2021
@zikaeroh
Copy link
Contributor

@zikaeroh zikaeroh commented Jul 26, 2021

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

Loading

@findleyr
Copy link
Contributor

@findleyr findleyr commented Jul 26, 2021

@zikaeroh that makes sense, thanks for the explanation!

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants