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

Jump to bottom

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

Closed
aykevl opened this issue Dec 13, 2020 · 4 comments
Closed

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

aykevl opened this issue Dec 13, 2020 · 4 comments
Assignees
@timothy-king
Labels
FrozenDueToAge Tools This label describes issues relating to any tools in the x/tools repository. Unfortunate
Milestone
Unreleased

Comments

@aykevl
Copy link

aykevl commented Dec 13, 2020

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.
@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Dec 13, 2020
@gopherbot gopherbot added this to the Unreleased milestone Dec 13, 2020
@aykevl aykevl mentioned this issue Dec 13, 2020
Closed
@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Dec 17, 2020
@toothrot
Copy link
Contributor

/cc @golang/tools-team

@timothy-king timothy-king self-assigned this Sep 16, 2022
@timothy-king
Copy link
Contributor

"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
Copy link

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

gopherbot pushed a commit to golang/tools that referenced this issue Oct 11, 2022
@timothy-king
cmd/ssadump: disable run mode with runtime package
ab79327 
Changes `ssadump -run` to ensure that the package runtime
is not imported (changed from must be imported). For several
years, the runtime package has used unsafe constructs
x/tools/go/ssa/interp cannot interpret. This must have been
failing a similar amount of time.

This is unfortunate, but is unlikely to be addressed soon.

For golang/go#43163

Change-Id: I9e2aee640ff7b1123e591e6c49cac9967c5e8da8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/441817
Run-TryBot: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@timothy-king timothy-king added Unfortunate and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Oct 11, 2022
@timothy-king
Copy link
Contributor

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.

@golang golang locked and limited conversation to collaborators Oct 11, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@timothy-king timothy-king

Labels
FrozenDueToAge Tools This label describes issues relating to any tools in the x/tools repository. Unfortunate
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
4 participants
@toothrot @aykevl @timothy-king @gopherbot