cmd/compile: OpInlMark can get removed by SSA dead code elimination, resulting in invalid inlining trees

[mdempsky]

See discussion at #46234.

The immediate issue is that https://go.dev/play/p/OikFLBmKguY?v=gotip causes the loop at

go/src/runtime/traceback.go

Line 362 in 7f632f7

for {

to never terminate, because the inlining "tree" has cycles.

The bigger issue is that we're generating trees like this for kube-apiserver, and this is presumably the root cause of #54593.

[mdempsky]

GOEXPERIMENT=nounified go build -gcflags=-d=pctab=pctoinline net/http produces:

funcpctab net/http.readTransfer [valfunc=pctoinline]
...
    7b      3 00123 (/usr/lib/google-golang/src/net/http/transfer.go:563)       MOVQ    CX, net/http.r+216(SP)
...
-- inlining tree for net/http.readTransfer:
0 | -1 | net/http/internal.NewChunkedReader (/usr/lib/google-golang/src/net/http/transfer.go:563:49) pc=1000
1 | 0 | bufio.NewReader ($GOROOT/src/net/http/internal/chunked.go:32:23) pc=0
2 | 1 | bufio.NewReaderSize ($GOROOT/src/bufio/bufio.go:63:22) pc=0
3 | 2 | bufio.(*Reader).reset ($GOROOT/src/bufio/bufio.go:57:9) pc=0
4 | -1 | io.LimitReader (/usr/lib/google-golang/src/net/http/transfer.go:568:37) pc=1472
5 | -1 | net/http.Header.get (/usr/lib/google-golang/src/net/http/transfer.go:530:47) pc=573
6 | -1 | net/http.bodyAllowedForStatus (/usr/lib/google-golang/src/net/http/transfer.go:550:60) pc=746
7 | -1 | net/http.noResponseBodyExpected (/usr/lib/google-golang/src/net/http/transfer.go:560:28) pc=845
8 | -1 | net/http.bodyAllowedForStatus (/usr/lib/google-golang/src/net/http/transfer.go:560:70) pc=845
--

Note the pc=0 value on entries 1 through 3, and that entry 3 is actually referenced by the MOVQ instruction.

The consequence of this is that when unwinding the stack at the MOVQ instruction, we'll find the bufio.(*Reader).reset call, but treat it as called directly by readTransfer, rather than transitively inlined via internal.NewChunkedReader->bufio.NewReader->bufio.NewReaderSize->bufio.(*Reader).reset.

[mdempsky]

Interestingly, that's the only function that ends up with a corrupt inline tree with GOEXPERIMENT=nounified that I could find.

[mdempsky]

Here's a minimized, standalone repro of the nounified failure:

package http

func readTransfer(r *bufioReader) any {
	return NewChunkedReader(r)
}

func NewChunkedReader(r any) any {
	br, ok := r.(*bufioReader)
	if !ok {
		br = new(bufioReader)
		reset(br, r)
	}
	return &chunkedReader{r: br}
}

type chunkedReader struct {
	r *bufioReader
}

type bufioReader struct {
	rd any
}

func reset(b *bufioReader, r any) {
	b.rd = r
}

Compiled with -d=pctab=pctoinline, this input produces:

-- inlining tree for command-line-arguments.readTransfer:
0 | -1 | command-line-arguments.NewChunkedReader (/home/mdempsky/wd/go/src/net/http/dummy.go:8:25) pc=25
1 | 0 | command-line-arguments.reset (/home/mdempsky/wd/go/src/net/http/dummy.go:15:8) pc=0
--

Again, note the bad pc=0 value.

[mdempsky]

Notably, the minimized test case repros with unified IR too, whereas the original net/http code did not.

[gopherbot]

Change https://go.dev/cl/425395 mentions this issue: cmd/compile/internal/noder: fix inlined function literal positions

[mdempsky]

Looking at GOSSAFUNC=readTransfer output, the issue with the corrupt inline tree above is that the OpInlMark for the inlined reset call gets removed, because it's determined to be dead code. But when we spill AX to the stack, we end up using the position information from the inlined b.rd = r assignment.

This seems to be an issue with the "expand calls" phase. The inserted OpArgIntReg value seems to be taking the position of its first use, rather than the position of the original OpArg.

/cc @dr2chase

[cuonglm]

@mdempsky seems related to https://go-review.googlesource.com/c/go/+/309649

[mdempsky]

@cuonglm Thanks, that seems plausible.

Further minimized repro:

package http

func readTransfer(r *int) {
	NewChunkedReader(r)
}

func NewChunkedReader(r *int) {
	if _, ok := any(r).(*int); !ok {
		// dead code path, but only recognized as such after "decompose builtins"
		reset(r)
	}
	sink = new(int) // force r to be spilled
	sink = r
}

func reset(r *int) {
	sink = r // anything that uses r
}

var sink any

[gopherbot]

Change https://go.dev/cl/425415 mentions this issue: cmd/internal/obj: report corrupt inline tree entries

[mdempsky]

CL 425415 adds a hacky check that we find valid PC offsets for all of the inline tree entries we emit. In particular, it reports the miscompilation of the test case above.

[cuonglm]

With this patch, above test case pass, ./make.bash run ok:

diff --git a/src/cmd/compile/internal/ssa/expand_calls.go b/src/cmd/compile/internal/ssa/expand_calls.go
index 90ea2d5040..d1a742c014 100644
--- a/src/cmd/compile/internal/ssa/expand_calls.go
+++ b/src/cmd/compile/internal/ssa/expand_calls.go
@@ -1773,7 +1773,7 @@ func (x *expandState) newArgToMemOrRegs(baseArg, toReplace *Value, offset int64,
                toReplace.Type = t
                w = toReplace
        } else {
-               w = baseArg.Block.NewValue0IA(pos, op, t, auxInt, aux)
+               w = baseArg.Block.NewValue0IA(aux.Name.Pos(), op, t, auxInt, aux)
        }
        x.commonArgs[key] = w
        if toReplace != nil {

But still fails for some tests:

# go run run.go -- fixedbugs/issue53982.go
exit status 2
# command-line-arguments
<autogenerated>:1: inline marker #0 still poisoned

FAIL	fixedbugs/issue53982.go	0.131s
# go run run.go -- typeparam/issue47775.go
exit status 1
/home/cuonglm/sources/go/test/typeparam/issue47775.dir/b.go:13:6: inline marker #0 still poisoned

FAIL	typeparam/issue47775.go	0.105s
# go run run.go -- typeparam/issue47775b.go
exit status 1
/home/cuonglm/sources/go/test/typeparam/issue47775b.go:21:5: inline marker #0 still poisoned

FAIL	typeparam/issue47775b.go	0.052s
# go run run.go -- typeparam/issue49432.go
exit status 1
/home/cuonglm/sources/go/test/typeparam/issue49432.go:13:6: inline marker #0 still poisoned

FAIL	typeparam/issue49432.go	0.058s
exit status 1

Sounds like we still mess the pos somewhere else.

[gopherbot]

Change https://go.dev/cl/425785 mentions this issue: cmd/compile: fix wrong position when rewriting to OpArg/OpArgXXX

[aclements]

What's the status of this? I see the CL was merged. Should we rebase and re-trybot CL 425415 to see if it reports any other failures?

[cuonglm]

What's the status of this? I see the CL was merged. Should we rebase and re-trybot CL 425415 to see if it reports any other failures?

See my comment in #54625 (comment)

Those tests still failed with current tip.

[mdempsky]

Should we rebase and re-trybot CL 425415 to see if it reports any other failures?

Done. Still reporting failures: https://storage.googleapis.com/go-build-log/eeb08b68/linux-amd64_bc78596a.log

Retitled to better reflect the current understanding of the issue, and bumping to 1.21.

[gopherbot]

Change https://go.dev/cl/468415 mentions this issue: cmd/compile/internal/noder: correct positions for synthetic closures

[mdempsky]

@cuonglm points out that CL 468415 addresses the failures reported by CL 425415. So I'll look into polishing that CL up to mail out for inclusion, at least during the dev cycle to help smoke out more failure cases.

I think the underlying issue around ssa's deadcode elimination pass and OpInlMarks is still applicable though.

[gopherbot]

Change https://go.dev/cl/471677 mentions this issue: [release-branch.go1.20] cmd/compile/internal/noder: correct positions for synthetic closures

[mknyszek]

Hey @mdempsky, doing a sweep of the Go 1.21 milestone. Any updates here?

Pushing to Backlog for now, feel free to move it to the Go 1.22 milestone if you plan to work on it. Thanks!