You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi go masters, I was developing an instrumentation framework(namely xgo) on top of the -overlay flag. I happened to encounter a build failure with the following specific building sequence:
go test succeeds
go test -overlay some_overlay.json fails
NOTE: the overlay contains a modified the file to include a new import: import "runtime", which causes the build failure
After investigation, I found this bug:
happens only when
two builds use the same GOCACHE
an overlay introduces new imports to the original file
the replaced file belongs to a third party module
was introduced in go1.19, last to latest go1.24 and possibly later
Below are the steps to reproduce this bug:
git clone --branch fix-xgo-v1.1.0 https://github.com/xhd2015/xgo
cd xgo/runtime/test/build/overlay_build_cache_error_with_go
go test -run TestGoModNonOverlayFirstShouldError -v ./
The test code that verifies the output:
funcTestGoModNonOverlayFirstShouldError(t*testing.T) {
overlayFile, err:=setupReverse("gomod_first")
iferr!=nil {
t.Fatalf("failed to setup reverse: %v", err)
}
// ensure we have a clean GOCACHEgocache, err:=getTmpGocache()
iferr!=nil {
t.Fatalf("failed to get tmp gocache: %v", err)
}
deferos.RemoveAll(gocache)
varnormOut bytes.Buffererr=cmd.Debug().Stdout(&normOut).Stderr(&normOut).Env([]string{"GOCACHE="+gocache, "GO_BYPASS_XGO=true"}).Run("go", "test", "-v", "./overlay_test_with_gomod")
iferr!=nil {
t.Log(normOut.String())
t.Fatalf("failed to run test: %v", err)
}
// this should failvarerrOut bytes.BufferafterErr:=cmd.Debug().Stdout(&errOut).Stderr(&errOut).Env([]string{"GOCACHE="+gocache, "GO_BYPASS_XGO=true"}).Run("go", "test", "-v", "-overlay", overlayFile, "./overlay_test_with_gomod")
goMinor, err:=getGo1MinorVersion()
iferr!=nil {
t.Fatalf("failed to get go minor version: %v", err)
}
// this issue was introduced in go1.19ifgoMinor>=19 {
ifafterErr==nil {
t.Errorf("expect cache+overlay combination error, actual nil")
}
expectContains:="could not import runtime (open : no such file or directory)"ifruntime.GOOS=="windows" {
expectContains="could not import runtime (open : The system cannot find the file specified.)"
}
errOutStr:=errOut.String()
if!strings.Contains(errOutStr, expectContains) {
t.Errorf("expect containing %q, actual none", expectContains)
t.Logf("DEBUG: %s", errOutStr)
return
}
} else {
ifafterErr!=nil {
t.Errorf("expect cache+overlay success, actual error: %v", afterErr)
}
}
}
My workaround(xhd2015/xgo#311 (comment)) is to modify the pkg loading under src/cmd/go/internal/load/pkg.go, to always import runtime for all packages except unsafe, internal/... and runtime/internal/....
But practically if the package is a third party package, this workaround won't work.
The underlying error actually comes from go tool compile, which sees an empty # import config file that resolves to empty packagefile of runtime, thus the error message. It's probably there is some bug when generating the import config file when invoking go tool compile.
More details can refer to the original issue link: xhd2015/xgo#311
What did you see happen?
The build fails with the message:
runtime_link.go:8: could not import runtime (open : no such file or directory)
What did you expect to see?
The build should compile with the same GOCACHE, regardless whether -overlay flag is present or not, and new imports introduced or not.
The text was updated successfully, but these errors were encountered:
The root reason is that go's module cache(GOMODCACHE) does treat modules readonly and immutable. So it won't be aware of that when you import new packages through -overlay.
That said, to bypass this issue, just don't import any extra packages, i.e. don't change the package's import sets.
If the instrumentation relies on external ability, do that via IR-link which can be done by instrumenting the compiler.
Go version
go version go1.23.6 darwin/arm64
Output of
go env
in your module/workspace:What did you do?
Hi go masters, I was developing an instrumentation framework(namely xgo) on top of the
-overlay
flag. I happened to encounter a build failure with the following specific building sequence:go test
succeedsgo test -overlay some_overlay.json
failsimport "runtime"
, which causes the build failureAfter investigation, I found this bug:
GOCACHE
Below are the steps to reproduce this bug:
The test code that verifies the output:
My workaround(xhd2015/xgo#311 (comment)) is to modify the pkg loading under
src/cmd/go/internal/load/pkg.go
, to always importruntime
for all packages exceptunsafe
,internal/...
andruntime/internal/...
.But practically if the package is a third party package, this workaround won't work.
The underlying error actually comes from
go tool compile
, which sees an empty# import config
file that resolves to empty packagefile ofruntime
, thus the error message. It's probably there is some bug when generating the import config file when invokinggo tool compile
.More details can refer to the original issue link: xhd2015/xgo#311
What did you see happen?
The build fails with the message:
What did you expect to see?
The build should compile with the same
GOCACHE
, regardless whether-overlay
flag is present or not, and new imports introduced or not.The text was updated successfully, but these errors were encountered: