cmd/go: hangs with 100% CPU on import of absolute path in the presence of go.mod #27558
Comments
|
@gopherbot modules |
|
Strace output can be found here: https://ptpb.pw/APnwN53-Q0MgIUSmM43aOVsPAxlq |
|
More information, an easy way to reproduce:
package main
import "/tmp/foo/bar"
func main() {
}Notes:
|
|
As I mentioned over in #27474 (comment):
Hence this issue only exists to tidy up a very uncommon edge case where someone has, by accident, used an absolute import path and the experience should be better than simply hanging. |
|
Just to clarify, relative import paths do work as long as the In the presence of
In the lack of presence of
And yes, that is exactly my answer to the question "What did you expect to see?". :P |
I note #20883, in particular #20883 (comment). Whilst relative imports might work in some situations outside of GOPATH in non-module mode (per @ianlancetaylor's comment), I think the behaviour in module-mode (whether inside or outside GOPATH) is undefined at best. As you say, good error messages will help remove the confusion. |
bcmills
added
the
NeedsFix
p = path.Dir(p) converges to either "." or "/". The current implementation of modload.QueryPackage() has a loop that terminates only on ".", not "/". This leads to the go command hanging in an infinite loop if the user manages to supply a file path starting with "/" as package path. An example of the issue is if the user (incorrectly) attempts to use an absolute directory path in an import statement within a module (import "/home/bob/myproj") and then runs go list. Fixes golang#27558
|
Change https://golang.org/cl/139098 mentions this issue: |
What version of Go are you using (
go version)?go version go1.11 linux/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?What did you do?
I tried to execute
go build main.go, wheremain.goimports an absolute path ("/home/bmeh/foo/logger").If file
go.moddoes not exist, it prints:main.go:4:8: import "/home/bmeh/foo/logger": cannot import absolute pathWhereas if I create
go.modviago mod init main(which doesn't makeloggera dependency, should it? In my opinion, it should, or perhaps in the future versions.), it hangs indefinitely, consuming 100% CPU. If I use./loggeras the import path, it doesn't hang, it printsbuild main: cannot find module for path _/home/bmeh/foo/loggerinstead, even thoughgo.modexists inlogger/and is properly vendored[1] viago mod vendor, but I guess that's not how you handle internal libraries anyway, just merely pointing out the inconsistency.It is worth mentioning that
go build main.gosucceeds in case there is nogo.modand the import path is./logger, all while being outside of$GOPATH, but of course it checks for the dependencies in$GOPATH. I am not even sure how to make a vendored version ofmain.gothat makeslogger/*(which is an internal library) a dependency, along with its own vendored dependencies.[2]Additionally, in case the import path in
main.gois an absolute path ("/home/bmeh/foo/logger"),go mod vendorhangs indefinitely as well, but if it's a relative path ("./logger"), it says:go: no dependencies to vendorTo sum up: both
go build, andgo mod vendorhangs in case an absolute path is imported ANDgo.modis present, ifgo.moddoesn't exist, it prints an error and exits. It works whengo.moddoesn't exist, and the import path is a relative path.[1] Further explanation needed as to why that's the case, or if there are any plans to change this behavior in future releases. Additionally, in my opinion, the error message is cryptic, and why does it append
_in front of it when I am clearly importing/home/bmeh/foo/logger?[2] Perhaps anyone could help me out with that?
Directory tree:
What did you expect to see?
Gracefully exit with a descriptive error message.
What did you see instead?
It hung indefinitely with 100% CPU usage.
@myitcv
The text was updated successfully, but these errors were encountered: