x/tools/cmd/ssadump: interpreting causes a crash

[aykevl]

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

$ go version
go version go1.15.5 linux/amd64

I've tested both Go 1.15.5 and Go 1.14.

Does this issue reproduce with the latest release?

Yes, in the latest major release and with x/tools commit d93e913.

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ayke/.cache/go-build"
GOENV="/home/ayke/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/ayke/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/ayke:/home/ayke"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/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-build217519519=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I have the following code in a directory named const:

package main

import _ "runtime"

func main() {
	println("test")
}

I run it with ssadump -run . when I'm in that directory (or alternatively ssadump -interp=RT -run .).

What did you expect to see?

I expect it to print "test".

What did you see instead?

It crashes:

$ ssadump -run .
Running: _/home/ayke/tmp/const
panic: runtime error: invalid memory address or nil pointer dereference

$ ssadump -interp=RT -run .
Running: _/home/ayke/tmp/const
Entering _/home/ayke/tmp/const.init.
.0:
	 t0 = *init$guard
	 if t0 goto 2 else 1
.1:
	 *init$guard = true:bool
	 t1 = runtime.init()
Entering runtime.init.
[... removed excessive log messages...]
Entering runtime.float64frombits at /usr/local/go/src/runtime/float.go:51:6.
.0:
	 t0 = new uint64 (b)
	 *t0 = b
	 t1 = convert unsafe.Pointer <- *uint64 (t0)
	 t2 = convert *float64 <- unsafe.Pointer (t1)
	 t3 = *t2
Leaving runtime.float64frombits, resuming runtime.init at /usr/local/go/src/runtime/float.go:9:26.
Leaving runtime.init, resuming _/home/ayke/tmp/const.init.
Leaving _/home/ayke/tmp/const.init.
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x689fa6]

goroutine 1 [running]:
golang.org/x/tools/go/ssa/interp.load(0x767420, 0x8cf9c0, 0x0, 0x400000c000487040, 0x3)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/value.go:338 +0x1a6
golang.org/x/tools/go/ssa/interp.unop(0xc0036288a0, 0x6a6860, 0x0, 0x6a6860, 0x0)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/ops.go:847 +0x739
golang.org/x/tools/go/ssa/interp.visitInstr(0xc004d43500, 0x76dd00, 0xc0036288a0, 0x4)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:195 +0x745
golang.org/x/tools/go/ssa/interp.runFrame(0xc004d43500)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:579 +0xdc
golang.org/x/tools/go/ssa/interp.callSSA(0xc004d219d0, 0xc004d42f00, 0x18600a, 0xc0005a92c0, 0xc004e754c0, 0x1, 0x1, 0x0, 0x0, 0x0, ...)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:524 +0x5da
golang.org/x/tools/go/ssa/interp.call(0xc004d219d0, 0xc004d42f00, 0x18600a, 0x7053c0, 0xc0005a92c0, 0xc004e754c0, 0x1, 0x1, 0x0, 0x80)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:462 +0xd5
golang.org/x/tools/go/ssa/interp.visitInstr(0xc004d42f00, 0x76c740, 0xc000a2ac80, 0x4)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:202 +0x886
golang.org/x/tools/go/ssa/interp.runFrame(0xc004d42f00)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:579 +0xdc
golang.org/x/tools/go/ssa/interp.callSSA(0xc004d219d0, 0xc004d42e80, 0x0, 0xc0015fbb80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:524 +0x5da
golang.org/x/tools/go/ssa/interp.call(0xc004d219d0, 0xc004d42e80, 0x0, 0x7053c0, 0xc0015fbb80, 0x0, 0x0, 0x0, 0x18, 0x80)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:462 +0xd5
golang.org/x/tools/go/ssa/interp.visitInstr(0xc004d42e80, 0x76c740, 0xc001265080, 0x4)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:202 +0x886
golang.org/x/tools/go/ssa/interp.runFrame(0xc004d42e80)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:579 +0xdc
golang.org/x/tools/go/ssa/interp.callSSA(0xc004d219d0, 0x0, 0x0, 0xc00153e500, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:524 +0x5da
golang.org/x/tools/go/ssa/interp.call(0xc004d219d0, 0x0, 0x0, 0x7053c0, 0xc00153e500, 0x0, 0x0, 0x0, 0xc000605bf8, 0x1f)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:462 +0xd5
golang.org/x/tools/go/ssa/interp.Interpret(0xc001cbd620, 0x3, 0x76ad20, 0xc00018c080, 0xc0000cbdc0, 0x15, 0x0, 0x0, 0x0, 0x2)
	/home/ayke/src/golang.org/x/tools/go/ssa/interp/interp.go:701 +0x5ec
main.doMain(0x0, 0x0)
	/home/ayke/src/golang.org/x/tools/cmd/ssadump/main.go:170 +0x78c
main.main()
	/home/ayke/src/golang.org/x/tools/cmd/ssadump/main.go:64 +0x26

---

What I really wanted to report was what appears to be a bug in either go/constant or x/tools/go/ssa, but I'm not sure how to reproduce this in an easy way with ssadump crashing on any program that I feed it.

[toothrot]

/cc @golang/tools-team

[timothy-king]

"runtime" is required by ssadump to interpret.

		if prog.ImportedPackage("runtime") == nil {
			return fmt.Errorf("-run: program does not depend on runtime")
		}

However, x/tools/go/ssa/interp can no longer handle runtime's use of unsafe.Pointer during package initialization.

	uint32Type *_type = efaceOf(&uint32Eface)._type

[gopherbot]

Change https://go.dev/cl/441817 mentions this issue: cmd/ssadump: disable run mode with runtime package

[timothy-king]

interp is only really needed for testing and a redesign to stub out "runtime" or fixing the memory model to unsafe.Pointer dereferences after type switches is quite a bit of work. We have decided to address this by giving a better error message in ssadump and not panicing. So it will continue to be the case that only trivial programs can be interpreted by ssadump.

Closing for now as unfortunate.