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: compiler segfaults in cmd/compile/internal/gc.markUsedIfaceMethod #45258

Closed
parabolala opened this issue Mar 26, 2021 · 7 comments
Closed
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.

Comments

@parabolala
Copy link

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

$ go version
go version go1.16.2 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/jenia/Library/Caches/go-build"
GOENV="/Users/jenia/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/jenia/go/pkg/mod"
GONOPROXY="..."
GONOSUMDB="..."
GOOS="darwin"
GOPATH="/Users/jenia/go"
GOPRIVATE="..."
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/local/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/local/lib/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.2"
GCCGO="gccgo"
AR="ar"
CC="/usr/bin/clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/tmp/worker/go.mod"
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/nk/w186v63s5kz_vcwvlt7t2rc40000gn/T/go-build489409122=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

https://play.golang.org/p/TGtWALJVzT9

What did you expect to see?

Program compiles

What did you see instead?

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0xb8c31d]

goroutine 1 [running]:
cmd/internal/obj.Addrel(...)
	/usr/local/go/src/cmd/internal/obj/data.go:195
cmd/compile/internal/gc.markUsedIfaceMethod(0xc0003b0a00)
	/usr/local/go/src/cmd/compile/internal/gc/walk.go:1625 +0x7d
cmd/compile/internal/gc.walkexpr(0xc0003b0a00, 0xc0000c34a8, 0x0)
	/usr/local/go/src/cmd/compile/internal/gc/walk.go:559 +0x3c79
cmd/compile/internal/gc.walkstmt(0xc0003b0a00, 0xc0003cc980)
	/usr/local/go/src/cmd/compile/internal/gc/walk.go:149 +0xd0b
cmd/compile/internal/gc.walkstmtlist(0xc0003c8580, 0x7, 0x8)
	/usr/local/go/src/cmd/compile/internal/gc/walk.go:81 +0x47
cmd/compile/internal/gc.walk(0xc0000a69a0)
	/usr/local/go/src/cmd/compile/internal/gc/walk.go:65 +0x3bd
cmd/compile/internal/gc.compile(0xc0000a69a0)
	/usr/local/go/src/cmd/compile/internal/gc/pgen.go:239 +0x85
cmd/compile/internal/gc.funccompile(0xc0000a69a0)
	/usr/local/go/src/cmd/compile/internal/gc/pgen.go:220 +0xc5
cmd/compile/internal/gc.Main(0xcc7d40)
	/usr/local/go/src/cmd/compile/internal/gc/main.go:762 +0x3525
main.main()
	/usr/local/go/src/cmd/compile/main.go:52 +0xb1

Note: this seems specific to the function name _. If I rename similar function to a proper function name, the code compiles (unless like in example here where it needs to be main to compile).

@ALTree
Copy link
Member

ALTree commented Mar 27, 2021

Similar issue reported in the past: #29870.

Anyway this seems to be fixed on tip. Go 1.15 is also not affected.

cc @randall77 for a decision about Go 1.16.

@ALTree ALTree added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Mar 27, 2021
@ALTree ALTree changed the title Compiler segfaults in cmd/compile/internal/gc.markUsedIfaceMethod cmd/compile: compiler segfaults in cmd/compile/internal/gc.markUsedIfaceMethod Mar 27, 2021
@cuonglm
Copy link
Member

cuonglm commented Apr 18, 2021

This bug was introduced in 39dde09, which use Curfn.Func.lsym unconditionally. For function name _, Curfn.Func.lsym is nil. The bug exists because for function name _, we don't generate code but still walk through it.

This was partially fixed in cc90e7a, since when we don't walk through function name _ anymore.

I think the right fix, is making reflectdata.MarkUsedIfaceMethod handle function name _ correctly. Though, It does not affect the functionality of the compiler at tip (because we only call reflectdata.MarkUsedIfaceMethod during walk), it makes shipping a backport to 1.16 more easily.

cc @cherrymui @mdempsky @randall77

@randall77
Copy link
Contributor

I don't think this needs a backport fix for 1.16. There is a trivial workaround (don't use _ as the function name).

This was partially fixed in cc90e7a, since when we don't walk through function name _ anymore.

Does tip still need a fix? I'm confused by the "partial" part of that statement.

@cuonglm
Copy link
Member

cuonglm commented Apr 18, 2021

@randall77 commit cc90e7a make function name _ isn't walked anymore, so the bug is disappear at tip, because reflectdata.MarkUsedIfaceMethod is only called during walk.

If it's called in other phases, e.g during typecheck, the bug is triggered again.

@randall77
Copy link
Contributor

If it's called in other phases, e.g during typecheck, the bug is triggered again.

So does that ever happen?

@cuonglm
Copy link
Member

cuonglm commented Apr 18, 2021

If it's called in other phases, e.g during typecheck, the bug is triggered again.

So does that ever happen?

No, at current tip.

@gopherbot
Copy link

Change https://golang.org/cl/311130 mentions this issue: cmd/compile: skip "_" function in reflectdata.MarkUsedIfaceMethod

@golang golang locked and limited conversation to collaborators Apr 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Development

No branches or pull requests

5 participants