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: crashes when -buildmode=shared is set and modules enabled #42189

shawn-xdji opened this issue Oct 24, 2020 · 4 comments

cmd/go: crashes when -buildmode=shared is set and modules enabled #42189

shawn-xdji opened this issue Oct 24, 2020 · 4 comments


Copy link

@shawn-xdji shawn-xdji commented Oct 24, 2020

What version of Go are you using (go version)?

$ go version
go version devel +d75b7f9648 Sat Oct 24 15:08:50 2020 +0000 linux/amd64

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?

go env Output
$ go env


What did you do?

Two crashes could be produced when running -buildmode=shared with 'go module' being enabled, depending on the package name, here are details with a reduced test-case:

step 1: create hello.go (outside $GOPATH and $GOROOT)

package main
import "fmt"
func main() {

step 2: create a go.mod, picking up a module name without hostname
$ go mod init mymodule

step 3:
$ go install -buildmode=shared std
$ go install -buildmode=shared -linkshared mymodule

panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
	/home/jixiangdong/util/go1.15/src/cmd/go/internal/work/action.go:818 +0x8e5
cmd/go/internal/work.(*Builder).cacheAction(0xc000540a00, 0xc000242180, 0x14, 0x0, 0xc0006cfb08, 0xc000242180)
	/home/jixiangdong/util/go1.15/src/cmd/go/internal/work/action.go:371 +0x9e
cmd/go/internal/work.(*Builder).linkSharedAction(0xc000540a00, 0x1, 0x1, 0xc00053d20a, 0x6, 0xc00038b540, 0xc00053d20a)

step 4:
If changing the package name in hello.go to anything else other than 'main' the compiler crashes with a different stack.

# /tmp/go-build927715808/b035/
panic: runtime error: makeslice: cap out of range

goroutine 1 [running]:
cmd/link/internal/loader.(*Loader).LoadSyms(0xc000606000, 0x872300)
	/home/jixiangdong/util/go1.15/src/cmd/link/internal/loader/loader.go:2161 +0x125
	/home/jixiangdong/util/go1.15/src/cmd/link/internal/ld/lib.go:550 +0x3d0

step 5:
turns out the module name is the direct reason, if changing it to something like then the compiler simply errors out:

         package mymodule is not in GOROOT (/home/jixiangdong/util/go1.15/src/mymodule)

What did you expect to see?

no crash, and meaningful error message

What did you see instead?

various crashes.

Copy link
Contributor Author

@shawn-xdji shawn-xdji commented Oct 24, 2020

I could produce the same crash as that of 'step 3' with a more complicated case even if the module has a hostname as its prefix.

@shawn-xdji shawn-xdji changed the title -buildmode=shared crashes if module name having no hostname cmd:go -buildmode=shared crashes with 'go mod' mode Oct 25, 2020
@shawn-xdji shawn-xdji changed the title cmd:go -buildmode=shared crashes with 'go mod' mode cmd/go -buildmode=shared crashes with 'go mod' mode Oct 25, 2020
@cagedmantis cagedmantis changed the title cmd/go -buildmode=shared crashes with 'go mod' mode cmd/go: crashes when -buildmode=shared is set and modules enabled Oct 28, 2020
@cagedmantis cagedmantis added this to the Backlog milestone Oct 28, 2020
Copy link

@cagedmantis cagedmantis commented Oct 28, 2020

Copy link

@bcmills bcmills commented Oct 28, 2020

The attached go env output appears to be truncated, and I'm a bit confused at why the path in the panic traceback indicates go1.15.

@shawn-xdji, can you confirm the version of the go command you are using, and how to installed it (i.e. built from source, from an release downloaded from, or from some other package manager)?

Copy link
Contributor Author

@shawn-xdji shawn-xdji commented Oct 29, 2020

@bcmills sorry for the confusion, /home/jixiangdong/util/go1.15 is built from source with the latest commit (d75b7f9 when I filed the issue), I named it go1.15 since it's synced after 1.15 was released, should be something like go.latest.

@bcmills bcmills removed the WaitingForInfo label Nov 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.