go1.17 stack traces are problematic

[cpuguy83]

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

$ go version
go version go1.17rc1 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="/Users/cpuguy83/go/bin"
GOCACHE="/Users/cpuguy83/Library/Caches/go-build"
GOENV="/Users/cpuguy83/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/cpuguy83/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/cpuguy83/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/cpuguy83/sdk/go1.17rc1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/cpuguy83/sdk/go1.17rc1/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.17rc1"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/cpuguy83/dev/test/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/h0/019q23y92j58nhjw33nyjd1h0000gn/T/go-build429528351=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Trying out the new stack traces in go1.17rc1.

I ran this program:

package main

import (
	"context"
	"fmt"
	"runtime"
)

type foo struct {
	A string
}

func main() {
	ch := make(chan struct{})
	h := "hello"
	go func() {
		getStack(context.Background(), h, 1, foo{}, &foo{})
		close(ch)
	}()
	<-ch
}

func getStack(ctx context.Context, _ string, _ int, _ foo, _ *foo) {
	buf := make([]byte, 32*1024*1024)
	runtime.Stack(buf, true)

	fmt.Println(string(buf))
}

I get this stack trace:

goroutine 18 [running]:
main.getStack({0x0, 0x0}, {0x0, 0x0}, 0x0, {{0x0, 0x0}}, 0x0)
	/Users/cpuguy83/dev/test/stack.go:25 +0x45
main.main.func1()
	/Users/cpuguy83/dev/test/stack.go:17 +0x54
created by main.main
	/Users/cpuguy83/dev/test/stack.go:16 +0x85

goroutine 1 [chan receive]:
main.main()
	/Users/cpuguy83/dev/test/stack.go:20 +0x91

As you can see all the function parameters come up as 0x0 (or {0x0...} depending on type).
This happens when the run happens in a goroutine. If I run this without the goroutine it gives the expected(-ish) values:

goroutine 1 [running]:
main.getStack({0x0, 0xc0000001a0}, {0xc000092f70, 0x1004b79}, 0x60, {{0x0, 0x0}}, 0x1015be5)
	/Users/cpuguy83/dev/test/stack.go:19 +0x45
 16 package main
main.main()
	/Users/cpuguy83/dev/test/stack.go:14 +0x4f

Outside of the fact that this just seems wrong, what worries me is I've often used these stack traces to track down dead locks in my code where, as an example, I can trace an argument being passed down the stack to find "Request A is blocked on a mutex, and request B is blocked on "system doing things" (maybe blocked in a syscall, an RPC request, etc...) because the argument value is consistent.

What did you expect to see?

Not 0x0 for argument values in the trace

What did you see instead?

0x0 for argument values in the trace

[seankhliao]

Duplicate of #45728

[cpuguy83]

Oh, thanks!