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

Closed
shawndx opened this issue Oct 24, 2020 · 5 comments
Closed

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

shawndx opened this issue Oct 24, 2020 · 5 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@shawndx
Copy link
Contributor

shawndx commented Oct 24, 2020 •
edited

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?

Yes.

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

go env Output
$ go env

GO111MODULE="auto"

GOARCH="amd64"

GOBIN=""

GOCACHE="/home/jixiangdong/.cache/go-build"

GOENV="/home/jixiangdong/.config/go/env"

GOEXE=""

GOFLAGS=""

GOHOSTARCH="amd64"

GOHOSTOS="linux"

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() {
	fmt.Println("Hello")
}

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]:
cmd/go/internal/work.(*Builder).linkSharedAction.func2(0x997f80)
	/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/libmymodule.so
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
cmd/link/internal/ld.(*Link).loadlib(0xc00014c000)
	/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 example.com/mymodule 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.
@shawndx
Copy link
Contributor Author

shawndx commented Oct 24, 2020

Update:
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.

@shawndx shawndx changed the title -buildmode=shared crashes if module name having no hostname cmd:go -buildmode=shared crashes with 'go mod' mode Oct 25, 2020
@shawndx shawndx 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 the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 28, 2020
@cagedmantis cagedmantis added this to the Backlog milestone Oct 28, 2020
@cagedmantis
Copy link
Contributor

/cc @bcmills @jayconrod @matloob

@bcmills
Copy link
Contributor

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 https://golang.org/dl/, or from some other package manager)?

@bcmills bcmills added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Oct 28, 2020
@shawndx
Copy link
Contributor Author

shawndx 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 Issue is not actionable because of missing required information, which needs to be provided. label Nov 2, 2020
@grolfcry grolfcry mentioned this issue Oct 13, 2021
Closed
@seankhliao
Copy link
Member

Obsoleted by #47788

@golang golang locked and limited conversation to collaborators Oct 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@cagedmantis @bcmills @gopherbot @seankhliao @shawndx