cmd/compile: stack growth within newobject sees junk pointer because of incorrect liveness info

[quentinmit]

Go 1.7 calls runtime.newobject before initializing all return parameters; if this happens during a GC, the GC will see garbage data on the stack. @dr2chase can fill in more details here.

[ianlancetaylor]

CC @randall77 @josharian

[dr2chase]

And we have a reproducer: https://play.golang.org/p/RiYHHWryIj

For a less-commented version of same test:

go build -gcflags -live deferr.go
# command-line-arguments
./deferr.go:8: live at entry to f: err
./deferr.go:10: live at call to writebarrierptr: err
./deferr.go:15: live at call to newobject: &err
...

That last line is wrong-wrong-wrong, because the result of newobject is assigned to &err -- i.e., it is live before it is initialized.

[dr2chase]

CC @dsnet

[dr2chase]

Note this is believed to be a result of https://go-review.googlesource.com/c/24213/ (according to @dsnet)

[ianlancetaylor]

The description of https://golang.org/cl/24213 says it does pretty much exactly what you describe as a symptom.

[ianlancetaylor]

@dr2chase Pretty sure this is the fix. What do you think?

--- a/src/cmd/compile/internal/gc/plive.go
+++ b/src/cmd/compile/internal/gc/plive.go
@@ -1181,6 +1181,7 @@ func livenessepilogue(lv *Liveness) {
        if hasdefer {
                for _, n := range lv.vars {
                        if n.IsOutputParamHeapAddr() {
+                               n.Name.Needzero = true
                                xoffset := n.Xoffset + stkptrsize
                                onebitwalktype1(n.Type, &xoffset, ambig)
                        }

[dsnet]

@ianlancetaylor, I cherry picked your change and used it to build and run a test that was failing on this issue. After 1000 runs, they all passed. For reference, it would fail on 734/1000 of them without this change.

[gopherbot]

CL https://golang.org/cl/24715 mentions this issue.