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.

Sign up for GitHub

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

cmd/go: panic in test with augmented GOPATH and symlink to 'self' #15201

Closed
myitcv opened this issue Apr 8, 2016 · 8 comments
Closed

cmd/go: panic in test with augmented GOPATH and symlink to 'self' #15201

myitcv opened this issue Apr 8, 2016 · 8 comments
Labels
FrozenDueToAge Vendoring
Milestone
Unplanned

Comments

@myitcv
Copy link
Member

myitcv commented Apr 8, 2016

This issue follows on from the golang-dev thread about a vendoring problem, specifically my response. In the repro repo linked to below, I'm trying to make the cmd/a binary go get-able (with vendor-ed dependencies, per this definition) whilst allowing the library developer to "vendor" dependencies via $GOPATH augmentation as part of his/her development/build workflow (good practice).

$ go version
go version go1.6 linux/amd64

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/tmp/tmp.040VgHSXdq/src/github.com/myitcv/go-vendoring/_vendor:/tmp/tmp.040VgHSXdq"
GORACE=""
GOROOT="/home/myitcv/gos"
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

Full repro details here (README gives details): https://github.com/myitcv/go-vendoring

The directory structure of the repro repo is as follows:

.
├── cmd
│   └── a
│       └── vendor -> ../../_vendor/src
├── mylib1
├── mylib2
└── _vendor
    ├── pkg
    │   └── linux_amd64
    │       ├── bitbucket.org
    │       │   └── pkg
    │       └── github.com
    │           └── pborman
    └── src
        ├── bitbucket.org
        │   └── pkg
        │       └── inflect
        └── github.com
            ├── myitcv
            │   └── go-vendoring -> ../../../..
            └── pborman
                └── uuid

As the README shows, the problem comes when you augment GOPATH to include _vendor (the tree under _vendor effectively has a reference to self as shown above) and then re-run go test ./...

$GOPATH at this point looks something like this:

/home/myitcv/gostuff/src/github.com/myitcv/go-vendoring/_vendor:/home/myitcv/gostuff

As you can see from the directory structure above (which is a tree -d of /home/myitcv/gostuff/src/github.com/myitcv/go-vendoring), there is a symlink in the first (higher precedence) $GOPATH entry to a directory outside of the first entry, specifically the directory from which we are running go test ./...

Per the README, I expected a successful second run of go test ./... but instead got the following panic:

panic: runtime error: slice bounds out of range

goroutine 1 [running]:
panic(0x93c000, 0xc82000e120)
        /usr/local/go/src/runtime/panic.go:464 +0x3e6
main.vendoredImportPath(0xc82030f000, 0xc8202c67c1, 0x17, 0x0, 0x0)
        /usr/local/go/src/cmd/go/pkg.go:460 +0x67b
main.loadImport(0xc8202c67c1, 0x17, 0xc820193b90, 0x69, 0xc82030f000, 0xc8201e71c8, 0xc8202c5050, 0x1, 0x1, 0x1, ...)
        /usr/local/go/src/cmd/go/pkg.go:336 +0xe52
main.(*Package).load(0xc82030f000, 0xc8201e71c8, 0xc8201c7500, 0x0, 0x0, 0x4)
        /usr/local/go/src/cmd/go/pkg.go:947 +0x4397
main.loadImport(0xc8201d62d1, 0x25, 0xc8201a5d40, 0x3c, 0xc8201d4000, 0xc8201e71c8, 0xc8201d6390, 0x1, 0x1, 0x1, ...)
        /usr/local/go/src/cmd/go/pkg.go:377 +0x84e
main.(*Package).load(0xc8201d4000, 0xc8201e71c8, 0xc8201c6700, 0x0, 0x0, 0xc)
        /usr/local/go/src/cmd/go/pkg.go:947 +0x4397
main.loadImport(0xc82019ab70, 0x7, 0xc820016044, 0x36, 0x0, 0xc8201e71c8, 0x0, 0x0, 0x0, 0x0, ...)
        /usr/local/go/src/cmd/go/pkg.go:377 +0x84e
main.loadPackage(0xc82019ab70, 0x7, 0xc8201e71c8, 0x0)
        /usr/local/go/src/cmd/go/pkg.go:1633 +0x13d8
main.packagesAndErrors(0xc820181890, 0x3, 0x3, 0x0, 0x0, 0x0)
        /usr/local/go/src/cmd/go/pkg.go:1678 +0x531
main.packagesForBuild(0xc82019a5e0, 0x1, 0x1, 0x0, 0x0, 0x0)
        /usr/local/go/src/cmd/go/pkg.go:1694 +0x82
main.runTest(0xc887e0, 0xc8200781d0, 0x1, 0x1)
        /usr/local/go/src/cmd/go/test.go:375 +0x14e
main.main()
        /usr/local/go/src/cmd/go/main.go:181 +0x783

Am I breaking a rule by symlinking in this way?

I hope not, because it feels like a nice clean solution to the go get problem I mention in my response to the aforementioned thread.
@ianlancetaylor ianlancetaylor changed the title panic in cmd/go test with augmented GOPATH and symlink to 'self' cmd/go: panic in test with augmented GOPATH and symlink to 'self' Apr 9, 2016
@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Apr 9, 2016
@ianlancetaylor
Copy link
Contributor

I don't think the go tool is going to support symlinks within GOPATH, but clearly it should fail in a nicer way.

@myitcv
Copy link
Member Author

myitcv commented Apr 9, 2016

@ianlancetaylor thanks, I always forget Windows in this equation which is I guess why, generally speaking, symlinks are not supported?

@alexbrainman
Copy link
Member

I always forget Windows in this equation which is I guess why, generally speaking, symlinks are not supported?

All recent Windows versions do support symlinks. And Go standard library does support symlinks on Windows (when available).

Alex

@myitcv
Copy link
Member Author

myitcv commented Apr 11, 2016

If, as it sounds like is the case, there isn't 100% support for symlinks across first-class Go platforms, has there been any thought given to a cmd/go (and friends) specific approach to provide symlink-like behaviour via regular files?

This need only be something known to cmd/go and friends, the file system would always take precedence, would be backwards compatible etc.

Purely a gut feeling based on vendoring discussions to date, but if there were "symlink"-like support within GOPATH then this would enable certain patterns for vendoring that are currently not possible.

@bradfitz
Copy link
Contributor

@myitcv, interesting thought.

@myitcv
Copy link
Member Author

myitcv commented Apr 11, 2016

@bradfitz happy to kick start a proposal (or similar, I'll read up on the proposal process) if you think it's worth it?

@myitcv myitcv mentioned this issue Apr 19, 2016
Closed
@myitcv myitcv mentioned this issue May 2, 2016
Closed
@mikioh mikioh mentioned this issue Oct 18, 2016
Closed
@rsc rsc mentioned this issue Oct 21, 2016
Closed
@gopherbot
Copy link

CL https://golang.org/cl/31665 mentions this issue.

@myitcv
Copy link
Member Author

myitcv commented Oct 25, 2016

Thanks @rsc

@golang golang locked and limited conversation to collaborators Oct 25, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Vendoring
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@bradfitz @ianlancetaylor @myitcv @gopherbot @alexbrainman