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

dgrr · 2021-09-18T16:55:25Z

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.

The text was updated successfully, but these errors were encountered:

cuonglm · 2021-09-18T17:02:53Z

Build ok with unified IR.

cc @danscales @randall77

ALTree · 2021-09-18T17:30:53Z

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

dgrr · 2021-09-18T17:34:44Z

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

cuonglm · 2021-09-18T17:38:03Z

@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 · 2021-09-18T17:46:24Z

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.

cuonglm · 2021-09-18T18:02:02Z

@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 · 2021-09-18T18:17:25Z

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

ALTree · 2021-09-18T18:21:27Z

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 · 2021-09-19T11:19:22Z

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 · 2021-09-19T16:30:43Z

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

danscales · 2021-09-20T04:00:19Z

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

cuonglm added the NeedsFix label Sep 18, 2021

cuonglm added this to the Go1.18 milestone Sep 18, 2021

danscales self-assigned this Sep 18, 2021

gopherbot closed this as completed in a83a558 Sep 20, 2021

rsc unassigned danscales Jun 23, 2022

golang locked and limited conversation to collaborators Jun 23, 2023

gopherbot added the FrozenDueToAge label Jun 23, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

dgrr commented Sep 18, 2021

cuonglm commented Sep 18, 2021

ALTree commented Sep 18, 2021

dgrr commented Sep 18, 2021

cuonglm commented Sep 18, 2021

ALTree commented Sep 18, 2021 •

edited

Loading

cuonglm commented Sep 18, 2021

gopherbot commented Sep 18, 2021

ALTree commented Sep 18, 2021 •

edited

Loading

dgrr commented Sep 19, 2021

gopherbot commented Sep 19, 2021

danscales commented Sep 20, 2021

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

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

Comments

dgrr commented Sep 18, 2021

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

cuonglm commented Sep 18, 2021

ALTree commented Sep 18, 2021

dgrr commented Sep 18, 2021

cuonglm commented Sep 18, 2021

ALTree commented Sep 18, 2021 • edited Loading

cuonglm commented Sep 18, 2021

gopherbot commented Sep 18, 2021

ALTree commented Sep 18, 2021 • edited Loading

dgrr commented Sep 19, 2021

gopherbot commented Sep 19, 2021

danscales commented Sep 20, 2021

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

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

ALTree commented Sep 18, 2021 •

edited

Loading

ALTree commented Sep 18, 2021 •

edited

Loading