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

cmd/compile/internal: nil pointer using labels on a function using generics. #48462

dgrr opened this issue Sep 18, 2021 · 11 comments
Assignees
Labels
Milestone

Comments

@dgrr
Copy link

@dgrr 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 this to the Go1.18 milestone Sep 18, 2021
@cuonglm
Copy link
Member

@cuonglm cuonglm commented Sep 18, 2021

Build ok with unified IR.

cc @danscales @randall77

Loading

@ALTree
Copy link
Member

@ALTree ALTree commented Sep 18, 2021

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

Loading

@dgrr
Copy link
Author

@dgrr dgrr commented Sep 18, 2021

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

Loading

@cuonglm
Copy link
Member

@cuonglm 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.

Loading

@ALTree
Copy link
Member

@ALTree 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.

Loading

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

@cuonglm 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.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 18, 2021

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

Loading

@ALTree
Copy link
Member

@ALTree 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.

Loading

@dgrr
Copy link
Author

@dgrr 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.

Loading

@gopherbot
Copy link

@gopherbot gopherbot commented Sep 19, 2021

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

Loading

@gopherbot gopherbot closed this in a83a558 Sep 20, 2021
@danscales
Copy link

@danscales danscales commented Sep 20, 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.

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).

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants