Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: FuncForPC FileLine returns autogenerated instead of actual path #51774

Open
vearutop opened this issue Mar 17, 2022 · 6 comments
Open

runtime: FuncForPC FileLine returns autogenerated instead of actual path #51774

vearutop opened this issue Mar 17, 2022 · 6 comments
Labels
NeedsInvestigation
Milestone

Comments

@vearutop
Copy link
Contributor

@vearutop vearutop commented Mar 17, 2022

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

$ go version
go version go1.18 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=""
GOCACHE="/Users/vearutop/Library/Caches/go-build"
GOENV="/Users/vearutop/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/vearutop/go/pkg/mod"
GONOPROXY="github.com/adjust,github.com/vearutop,github.com/Unbotify"
GONOSUMDB="github.com/adjust,github.com/vearutop,github.com/Unbotify"
GOOS="darwin"
GOPATH="/Users/vearutop/go"
GOPRIVATE="github.com/adjust,github.com/vearutop,github.com/Unbotify"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/vearutop/sdk/go1.18"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/vearutop/sdk/go1.18/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/vearutop/gohack/github.com/cucumber/godog/go.mod"
GOWORK=""
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/n7/jv2b0zv57jzc8y6zhmfzbn7c0000gn/T/go-build1890007164=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I was getting file and line of struct method.

https://go.dev/play/p/VFs8FKAkTLf

package main

import (
	"reflect"
	"runtime"
)

type s struct{}

func (tc *s) f() {}

func main() {
	tc := &s{}

	v := reflect.ValueOf(tc.f)
	ptr := v.Pointer()
	f := runtime.FuncForPC(ptr)
	file, line := f.FileLine(f.Entry())
	name := f.Name()

	println(file, line, name)
}

What did you expect to see?

.../main.go 10 main.(*s).f-fm

What did you see instead?

<autogenerated> 1 main.(*s).f-fm

The issue is reproducible with go1.18 and gotip, however go1.18rc1 and below (go1.17) works as expected.

@heschi
Copy link
Contributor

@heschi heschi commented Mar 18, 2022

@heschi heschi added the NeedsInvestigation label Mar 18, 2022
@heschi heschi added this to the Go1.19 milestone Mar 18, 2022
@jakebailey
Copy link

@jakebailey jakebailey commented Mar 18, 2022

Bisects to CL 388794 (I was curious).

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Mar 18, 2022

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Mar 18, 2022

I'm not really sure what the right answer to be here. Technically this function is indeed autogenerated, as it is a closure capturing the receiver. This is also seen in the synthetic name (-fm). So I would expect a synthetic location. Both the runtime and reflect packages' documentation doesn't mention what is expected in this case.

We may be able to restore the old behavior, but I'm not sure that is best. If we want to give the location of the definition, perhaps we also want to give the original method name instead of the synthetic -fm name?

If you use the method that does not capture the receiver, like

v := reflect.ValueOf((*s).f)

It prints the actual line number. Would that be okay? Thanks.

@vearutop
Copy link
Contributor Author

@vearutop vearutop commented Mar 19, 2022

In my case using (*s).f does not seem feasible, as I receive functions from library users and they may provide any kind. Later, I print file and line of that function to help users to diagnose the problems, unfortunately <autogenerated> is not helpful in such scenario.

If there is a workaround or a more reliable solution to resolve arbitrary function into a place of origin in code, I would be happy to use it.

@e-nikolov
Copy link

@e-nikolov e-nikolov commented Apr 6, 2022

This is also affecting https://github.com/go-chai/chai, which is a http router extension that generates a swagger spec based on the new generics. It used to work with go1.18beta2.

The way I use it is

chai.Get(r, "/{id}", controller.SomeHandler)

runtime.FuncForPC then finds the file and line where SomeHandler is defined so it could use the AST and parse some swagger annotations from the comment above that function.

Now it returns <autogenerated> and the rest fails.

I wonder how Delve figures out the line numbers of functions when debugging and if it can be used for this sort of thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation
Projects
None yet
Development

No branches or pull requests

6 participants