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/compile/internal: nil pointer using labels on a function using generics. #48462

Closed
dgrr opened this issue Sep 18, 2021 · 11 comments
Closed
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@dgrr
Copy link

dgrr commented Sep 18, 2021

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

$ go version
go version devel go1.18-c894b442d1 Sat Sep 18 06:04:41 2021 +0000 darwin/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=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/hidden/Library/Caches/go-build"
GOENV="/Users/hidden/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/hidden/go/pkg/mod"
GOOS="darwin"
GOPATH="/Users/hidden/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/HEAD-c894b44/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/HEAD-c894b44/libexec/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.18-c894b442d1 Sat Sep 18 06:04:41 2021 +0000"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/9x/9mjczs3s0z3cg0tl19dhzx5w0000gn/T/go-build3207431654=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I tried to use a generic function that uses labels from another package.
Example code here

What did you expect to see?

A successful build.

What did you see instead?

# command-line-arguments
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x16461e1]

goroutine 1 [running]:
cmd/compile/internal/ssa.(*Block).AddEdgeTo(...)
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssa/block.go:274
cmd/compile/internal/ssagen.(*state).stmt(0xc00036ee00, {0x1a461b0, 0xc0004663f0})
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/ssa.go:1730 +0x1461
cmd/compile/internal/ssagen.(*state).stmtList(0xc00036ee00, {0xc00010bd90, 0x1, 0xc0004b7940})
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/ssa.go:1373 +0x5d
cmd/compile/internal/ssagen.(*state).stmt(0xc00036ee00, {0x1a46ef8, 0xc00046e150})
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/ssa.go:1677 +0x2d95
cmd/compile/internal/ssagen.(*state).stmtList(0xc00036ee00, {0xc0001641c0, 0x2, 0xc0004b7480})
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/ssa.go:1373 +0x5d
cmd/compile/internal/ssagen.(*state).stmt(0xc00036ee00, {0x1a46b10, 0xc0000a4fc0})
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/ssa.go:1780 +0x20c9
cmd/compile/internal/ssagen.(*state).stmtList(0xc00036ee00, {0xc0000fbce0, 0x7, 0xc0004b6fc0})
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/ssa.go:1373 +0x5d
cmd/compile/internal/ssagen.(*state).stmt(0xc00036ee00, {0x1a46b10, 0xc0000a4f30})
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/ssa.go:1780 +0x20c9
cmd/compile/internal/ssagen.(*state).stmtList(0xc00036ee00, {0xc00036e500, 0xa, 0x1a2d340})
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/ssa.go:1373 +0x5d
cmd/compile/internal/ssagen.buildssa(0xc00043ec60, 0x0)
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/ssa.go:566 +0x1d13
cmd/compile/internal/ssagen.Compile(0xc00043ec60, 0xc0000a0020)
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/ssagen/pgen.go:183 +0x4c
cmd/compile/internal/gc.compileFunctions.func4.1(0x1)
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/gc/compile.go:153 +0x3a
cmd/compile/internal/gc.compileFunctions.func2(0x0)
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/gc/compile.go:125 +0x1e
cmd/compile/internal/gc.compileFunctions.func4({0xc00010bea0, 0x2, 0x2})
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/gc/compile.go:152 +0x53
cmd/compile/internal/gc.compileFunctions()
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/gc/compile.go:163 +0x162
cmd/compile/internal/gc.Main(0x19050b0)
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/internal/gc/main.go:309 +0xfca
main.main()
	/usr/local/Cellar/go/HEAD-c894b44/libexec/src/cmd/compile/main.go:55 +0xdd

Remark: I think this is because of the labels in the generic function. See the last code attached to the play.golang.com. If you remove the labels, it works.
Remark 2: If you place the Unique function in the package main file, then it works. If you use that function from another package then it shows the panic message above.

@cuonglm cuonglm added the NeedsFix The path to resolution is known, but the work has not been done. label Sep 18, 2021
@cuonglm cuonglm added this to the Go1.18 milestone Sep 18, 2021
@cuonglm
Copy link
Member

cuonglm commented Sep 18, 2021

Build ok with unified IR.

cc @danscales @randall77

@ALTree
Copy link
Member

ALTree commented Sep 18, 2021

I think this is the same as #47960 and thus already reported in #46704.

@dgrr
Copy link
Author

dgrr commented Sep 18, 2021

Ah yes it is. Duplicated then. You can close it if you want, I'll track the others. Thanks!

@cuonglm
Copy link
Member

cuonglm commented Sep 18, 2021

@ALTree I think we should keep this open, as typeparam/mdempsky/4.go was already resolved in https://go-review.googlesource.com/c/go/+/349012, though the fix is incomplete.

@ALTree
Copy link
Member

ALTree commented Sep 18, 2021

Thank you. The thread at #46704 is quite hard to read, I have to say. There are no reproducers (they're in gerrit), no crash messages (so the thread cannot be found using the github search bar by people rediscovering these issues) and no checklist with a list of the issues and their status (fixed, unfixed, supposedly fixed but still triggerable)...

Overall I think it may be beneficial to reassess #46704 as a whole and maybe close it (after opening one issue for each remaining problem, with reproducer and searchable crash message / stacktrace). Because it's starting to get pretty confusing.

@danscales danscales self-assigned this Sep 18, 2021
@cuonglm
Copy link
Member

cuonglm commented Sep 18, 2021

@ALTree AFAICT, #46704 is likely a meta issue, and it's there for bigger picture, tracking the stable of two generics implementation (-G=3 and unified IR), rather than just concrete failed case for either one of them.

@gopherbot
Copy link

Change https://golang.org/cl/350696 mentions this issue: cmd/compile: fully fix handling of label in importReader

@ALTree
Copy link
Member

ALTree commented Sep 18, 2021

I understand that, but this makes it hard to keep track of which issues affect the current (non-unified) generic implementation, especially since crashes affecting non-unified get closed as dups of #46704 (like #47960).

Anyway I agree this one should stay open.

@dgrr
Copy link
Author

dgrr commented Sep 19, 2021

Build ok with unified IR.

cc @danscales @randall77

I spotted a few other problems too, but all of them were solved using the GOEXPERIMENT=unified, for example, in this program it complains about the Iter function, but with the IR works well.

Just so can take those cases into account. Thanks.

@gopherbot
Copy link

Change https://golang.org/cl/350911 mentions this issue: cmd/compile: fix export/import of range loop.

@danscales
Copy link
Contributor

Thank you. The thread at #46704 is quite hard to read, I have to say. There are no reproducers (they're in gerrit), no crash messages (so the thread cannot be found using the github search bar by people rediscovering these issues) and no checklist with a list of the issues and their status (fixed, unfixed, supposedly fixed but still triggerable)...

Overall I think it may be beneficial to reassess #46704 as a whole and maybe close it (after opening one issue for each remaining problem, with reproducer and searchable crash message / stacktrace). Because it's starting to get pretty confusing.

Yes, actually, I had been meaning to close #46704, for some of the reasons you mention, but especially now that all of the issues mentioned are fixed (esp. now that the extra fix in this issue is in).

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants