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

[ALTree]

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

[cuonglm]

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

[mdempsky]

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?

[cuonglm]

@mdempsky I did some investigation already, the problem is after CL 281352, the closure var &st isn't pushed to fn.Dcl in frontend anymore, so gc.prepareFunc won't see it. In SSA, we did add it to fn.Dcl in buildssa, then calling emitStackObjects inside genssa.

I will be AFK for couple of hours, I can try a fix when I'm back.

[mdempsky]

@cuonglm Thanks. No rush on the fix if you're interested in it.

Hm, I can believe that's the issue, but I'm not immediately seeing how it led to this issue. Do you mind getting the output from ir.Dump("dcl", fn.Dcl) in both gc.prepareFunc and ssagen.emitStackObjects, both before and after that CL and maybe at tip of dev.regabi too? (I've made further closure changes since then, so it's possible there are multiple CLs in play here.)

Sorry for asking so much. Also, if simply moving the sym generation to emitStackObjects fixes the issue and passes the racecompile slowbot, I think it's reasonable to go ahead and commit that while we continue understanding why it failed in the first place.

[mdempsky]

Oh, and finally: are we crashing trying to write out stack objects for f or for f.func1?

[mdempsky]

@ALTree 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.)

[cuonglm]

Oh, and finally: are we crashing trying to write out stack objects for f or for f.func1?

it's f.func1.

[mdempsky]

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

[gopherbot]

Change https://golang.org/cl/284112 mentions this issue: [dev.regabi] cmd/compile: create stkobj symbol inside emitStackObjects

[ALTree]

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.

[mdempsky]

@ALTree No apology needed. I'd rather a fuzzer discover compiler issues than an end user. :)

[gopherbot]

Change https://golang.org/cl/284075 mentions this issue: [dev.regabi] cmd/compile: don't promote Byval CaptureVars if Addrtaken

[gopherbot]

Change https://golang.org/cl/284076 mentions this issue: [dev.regabi] cmd/compile: move stkobj symbol generation to SSA

[gopherbot]

Change https://golang.org/cl/284077 mentions this issue: [dev.regabi] cmd/compile: unexport reflectdata.WriteType