go: cmd/compile: panic: runtime error: invalid memory address or nil pointer dereference [dev.regabi]

dev.regabi branch

$ gotip version
go version devel +35b9c66601 Thu Jan 14 17:35:39 2021 +0000 linux/amd64

package p

func f() {
	var st struct {
		s string
		i int16
	}
	_ = func() {
		var m map[int16]int
		m[st.i] = 0
	}
}

$ gotip tool compile crash.go 
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x51bd59]

goroutine 21 [running]:
cmd/internal/obj.(*LSym).prepwrite(0x0, 0xc00031c000, 0x0, 0x8)
	/home/alberto/go/src/cmd/internal/obj/data.go:71 +0x119
cmd/internal/obj.(*LSym).WriteInt(0x0, 0xc00031c000, 0x0, 0x8, 0x1)
	/home/alberto/go/src/cmd/internal/obj/data.go:100 +0x4d
cmd/compile/internal/objw.UintN(0x0, 0x0, 0x1, 0x8, 0x1)
	/home/alberto/go/src/cmd/compile/internal/objw/objw.go:34 +0x6e
cmd/compile/internal/objw.Uintptr(...)
	/home/alberto/go/src/cmd/compile/internal/objw/objw.go:27
cmd/compile/internal/ssagen.emitStackObjects(0xc000389da0, 0xc0000ea150)
	/home/alberto/go/src/cmd/compile/internal/ssagen/ssa.go:6492 +0x22a
cmd/compile/internal/ssagen.genssa(0xc000083500, 0xc0000ea150)
	/home/alberto/go/src/cmd/compile/internal/ssagen/ssa.go:6525 +0xf2
cmd/compile/internal/ssagen.Compile(0xc0000fa420, 0x0)
	/home/alberto/go/src/cmd/compile/internal/ssagen/pgen.go:178 +0x2a5
cmd/compile/internal/gc.compileFunctions.func2.1(0xc000308310, 0xc0000fa420, 0xc0000b8550, 0xc0000b6ce0)
	/home/alberto/go/src/cmd/compile/internal/gc/compile.go:143 +0x65
created by cmd/compile/internal/gc.compileFunctions.func2
	/home/alberto/go/src/cmd/compile/internal/gc/compile.go:141 +0x8e

cc @mdempsky @cuonglm

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 15 (11 by maintainers)

Commits related to this issue

[dev.regabi] cmd/compile: don't promote Byval CaptureVars if Addrtaken We decide during escape analysis whether to pass closure variables by value or reference. One of the factors that's considered i... — committed to golang/go by mdempsky 3 years ago
[dev.regabi] cmd/compile: move stkobj symbol generation to SSA The code for allocating linksyms and recording that we need runtime type descriptors is now concurrent-safe, so move it to where those s... — committed to golang/go by mdempsky 3 years ago
[dev.regabi] cmd/compile: unexport reflectdata.WriteType WriteType isn't safe for direct concurrent use, and users should instead use TypeLinksym or another higher-level API provided by reflectdata. ... — committed to golang/go by mdempsky 3 years ago

Most upvoted comments

Oh, that’s surprising. I didn’t expect f.func1 needed stack objects. I assumed f was crashing.

mdempsky on Jan 15, 2021

Thanks for the issue report and the reproducer. I’m assuming that’s minimized down from some real world code? If so, are you able to share that? (Not important, just curious.)

@mdempsky Sorry, there’s no real world code; the crasher was found by a fuzzer.

ALTree on Jan 15, 2021

Thanks. I’m guessing the test case tickles some mismatch between the logic in gc.prepareFunc for deciding whether to create the stkobj symbol, and the code in ssagen.emitStackObjects.

I wonder if we can just move that code from gc.prepareFunc to ssagen.emitStackObjects? The comments say that code isn’t safe to run during SSA generation, but I don’t think that’s true anymore. At least looking at them briefly, I see mutexes being used. I’d recommend trying to relocate the code and see if it passes the racecompile trybot.

It would also be interesting to know what variables are being caught by ssagen.emitStackObjects but missed by gc.prepareFunc. Not because it’s necessary for the fix per se, but to double-check that we understand the failure.

@cuonglm Do you want to look into fixing this?

mdempsky on Jan 15, 2021

git bisect points to https://go-review.googlesource.com/c/go/+/281352

cuonglm on Jan 15, 2021