cmd/compile: invalid memory address or nil pointer dereference in gc.convlit1

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

Installing tip at 3bea90d (can't use gotip version because it failed to build).

Does this issue reproduce with the latest release?

N/A

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jake/.cache/go-build"
GOENV="/home/jake/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jake/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build095132304=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Ran gotip download to build the latest tip.

What did you expect to see?

A successful build.

What did you see instead?

$ gotip download
Updating the go development tree...
remote: Counting objects: 58, done
remote: Finding sources: 100% (38/38)
remote: Total 38 (delta 9), reused 27 (delta 9)
Unpacking objects: 100% (38/38), done.
From https://go.googlesource.com/go
   498eaee4..3bea90d8  master     -> origin/master
Previous HEAD position was 498eaee4 cmd/internal/obj/x86: mark 2-instruction TLS access nonpreemptible
HEAD is now at 3bea90d8 cmd/go: allow a fork with path […]/vN to replace gopkg.in/[…].vN
Building Go cmd/dist using /usr/lib/go. (go1.13.4 linux/amd64)
Building Go toolchain1 using /usr/lib/go.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for linux/amd64.
# crypto/des
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x54 pc=0xc0d48b]

goroutine 1 [running]:
cmd/compile/internal/gc.convlit1(0xc0004bda80, 0xc000100a80, 0xc0003bfa00, 0xc0003bf780, 0xc0004dff01)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/const.go:246 +0xfb
cmd/compile/internal/gc.assignconvfn(0xc0004bda80, 0xc000100a80, 0xc0003bf780, 0xc0004dff80)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/subr.go:805 +0x9e
cmd/compile/internal/gc.assignconv(0xc0004bda80, 0xc000100a80, 0xe4f344, 0xd, 0xc0004dff80)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/subr.go:792 +0x70
cmd/compile/internal/gc.typecheckarraylit(0xc000100a80, 0x10, 0xc0004bd380, 0x10, 0x10, 0xe4f344, 0xd, 0x10)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:2999 +0x16a
cmd/compile/internal/gc.typecheckcomplit(0xc0004bd300, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:2807 +0x1cb8
cmd/compile/internal/gc.typecheck1(0xc0004bd300, 0x2, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:860 +0x44f9
cmd/compile/internal/gc.typecheck(0xc0004bd300, 0x2, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:300 +0x704
cmd/compile/internal/gc.typecheckarraylit(0xc0004c3ec0, 0x4, 0xc0004b8e00, 0x4, 0x4, 0xe4f344, 0xd, 0x4)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:2998 +0x135
cmd/compile/internal/gc.typecheckcomplit(0xc0004bc080, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:2807 +0x1cb8
cmd/compile/internal/gc.typecheck1(0xc0004bc080, 0x2, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:860 +0x44f9
cmd/compile/internal/gc.typecheck(0xc0004bc080, 0x2, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:300 +0x704
cmd/compile/internal/gc.typecheckarraylit(0xc0004c3f20, 0x8, 0xc000468500, 0x8, 0x8, 0xe4f344, 0xd, 0x30)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:2998 +0x135
cmd/compile/internal/gc.typecheckcomplit(0xc0004a1d00, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:2807 +0x1cb8
cmd/compile/internal/gc.typecheck1(0xc0004a1d00, 0x12, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:860 +0x44f9
cmd/compile/internal/gc.typecheck(0xc0004a1d00, 0x12, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:300 +0x704
cmd/compile/internal/gc.typecheckas(0xc0004c0500)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:3172 +0xa1
cmd/compile/internal/gc.typecheck1(0xc0004c0500, 0x1, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:1900 +0x2fcc
cmd/compile/internal/gc.typecheck(0xc0004c0500, 0x1, 0x0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/typecheck.go:300 +0x704
cmd/compile/internal/gc.Main(0xe6ebd0)
	/home/jake/sdk/gotip/src/cmd/compile/internal/gc/main.go:580 +0x2a6c
main.main()
	/home/jake/sdk/gotip/src/cmd/compile/main.go:50 +0xac
go tool dist: FAILED: /home/jake/sdk/gotip/pkg/tool/linux_amd64/go_bootstrap install -gcflags=all= -ldflags=all= std cmd: exit status 2
gotip: failed to build go: exit status 2

Rerunning gotip download was successful, so I'm not sure how reproducible this is.

@randall77 @griesemer
@josharian @mdempsky @martisch

Is the failure reproducible or was it one time?

I suspect runtime memory corruption if it doesn't reproduce.

As far as I can tell, it's a one-off or just really rare. I haven't seen it since, but I haven't rebuilt the toolchain all that many times today. (I get the corruption in #35326 way more often and consistently.)

Yeah, runtime memory corruption seems most likely to me then.

The nil pointer dereference happened here:

go/src/cmd/compile/internal/gc/const.go

Line 246 in 72f333a

if n.Type.Etype == TNIL {

But just a few lines earlier we have:

go/src/cmd/compile/internal/gc/const.go

Lines 230 to 233 in 72f333a

    
           if n == nil || n.Type == nil { 
        
           	// Allow sloppy callers. 
        
           	return n 
        
           }

The only intermediate code that modifies n or n.Type is:

go/src/cmd/compile/internal/gc/const.go

Lines 239 to 243 in 72f333a

    
           if n.Op == OLITERAL { 
        
           	// Can't always set n.Type directly on OLITERAL nodes. 
        
           	// See discussion on CL 20813. 
        
           	n = n.rawcopy() 
        
           }

but that just calls

go/src/cmd/compile/internal/gc/subr.go

Lines 387 to 390 in 72f333a

    
           func (n *Node) rawcopy() *Node { 
        
           	copy := *n 
        
           	return &copy 
        
           }

which is plainly safe.

@zikaeroh, I assume this is on the same 5.3.x kernel as you reported in #35326? If so, this is almost certainly the same issue (though having more data points is useful).

Yep, that's correct. I was just about to comment on your mega issue with a link here.

Feel free to close this in favor of #35777 once you've gotten whatever info you wanted.

Thanks. I've added this to the super-bug. Since this isn't reproducible, closing in favor of the super-bug.

	if n == nil \|\| n.Type == nil {
	// Allow sloppy callers.
	return n
	}

	if n.Op == OLITERAL {
	// Can't always set n.Type directly on OLITERAL nodes.
	// See discussion on CL 20813.
	n = n.rawcopy()
	}

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?

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

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