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/go: data race on (*load.PackageInternal).Gcflags field #31230

Open
bcmills opened this Issue Apr 3, 2019 · 2 comments

Comments

Projects
None yet
2 participants
@bcmills
Copy link
Member

commented Apr 3, 2019

The race was observed at head with go test -race cmd/go, but doesn't always reproduce.

        WARNING: DATA RACE
        Read at 0x00c00037e8b0 by goroutine 17:
          cmd/go/internal/work.gcToolchain.gc()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/gc.go:105 +0xc83
          cmd/go/internal/work.(*gcToolchain).gc()
              <autogenerated>:1 +0x107
          cmd/go/internal/work.(*Builder).build()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/exec.go:642 +0x1fd4
          cmd/go/internal/work.(*Builder).Do.func1()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/exec.go:107 +0x465
          cmd/go/internal/work.(*Builder).Do.func2()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/exec.go:164 +0x97

        Previous write at 0x00c00037e8b0 by goroutine 16:
          cmd/go/internal/load.setToolFlags()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/load/pkg.go:1800 +0x184
          cmd/go/internal/load.LoadImportWithFlags()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/load/pkg.go:1726 +0xe9
          cmd/go/internal/work.gcToolchain.symabis()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/gc.go:307 +0x2ea
          cmd/go/internal/work.(*gcToolchain).symabis()
              <autogenerated>:1 +0x8c
          cmd/go/internal/work.(*Builder).build()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/exec.go:606 +0x183f
          cmd/go/internal/work.(*Builder).Do.func1()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/exec.go:107 +0x465
          cmd/go/internal/work.(*Builder).Do.func2()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/exec.go:164 +0x97

        Goroutine 17 (running) created at:
          cmd/go/internal/work.(*Builder).Do()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/exec.go:151 +0x66e
          cmd/go/internal/test.runTest()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/test/test.go:752 +0x15cf
          main.main()
              /usr/local/google/home/bcmills/go/src/cmd/go/main.go:213 +0xa09

        Goroutine 16 (running) created at:
          cmd/go/internal/work.(*Builder).Do()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/work/exec.go:151 +0x66e
          cmd/go/internal/test.runTest()
              /usr/local/google/home/bcmills/go/src/cmd/go/internal/test/test.go:752 +0x15cf
          main.main()
              /usr/local/google/home/bcmills/go/src/cmd/go/main.go:213 +0xa09

@bcmills bcmills added this to the Go1.13 milestone Apr 3, 2019

@jayconrod

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2019

Note to future self: nothing from Builder.Do should call LoadImportWithFlags. Package loading accesses global mutable caches and is not concurrency safe.

@jayconrod

This comment has been minimized.

Copy link
Contributor

commented Apr 4, 2019

@aclements, could you take a look at gcToolchain.symabis? I think there's a bigger issue here, but I'm not sure I understand what's being done well enough to fix it.

The race is triggered by symbabis calling load.LoadImportWithFlags (previously known as LoadPackage), which is not thread safe. It reads and writes global state (in particular, flags in the loaded package), so it shouldn't be called inside an action.

symabis calls load.LoadImportWithFlags for a few specific packages (runtime, runtime/internal/atomic, sync/atomic) for other packages that depend on them. So in addition to the data race, it seems like there's a cyclic dependency that might not be recorded. For example, assembly files in sync/atomic are read when building runtime/internal/atomic, but I don't think that's recorded in the action id, so a change in one of those files wouldn't trigger a rebuild of runtime/internal/atomic.

Is there another way to implement this that avoids reading those files inside an action?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.