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: runtime.Caller() => "<autogenerated>" #16723

thockin opened this issue Aug 16, 2016 · 4 comments


None yet
6 participants
Copy link

commented Aug 16, 2016

I was playing with a method that wants to print the file:line of the caller. runtime.Caller(1) seems like it should do the trick, but I get ':2'. If I call runtime.Caller(2) instead it seems to work, but I am reluctant to depend on that.

It looks like this has to do with being an interface method:

Is there a generic way to get the actual caller, safely, in all cases?

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

go version go1.6.1 linux/amd64

  1. What operating system and processor architecture are you using (go env)?

GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"

@bradfitz bradfitz changed the title runtime.Caller() => "<autogenerated>" runtime: runtime.Caller() => "<autogenerated>" Aug 16, 2016

@quentinmit quentinmit added this to the Go1.8 milestone Aug 26, 2016


This comment has been minimized.

Copy link

commented Nov 11, 2016

The interface call calls a wrapper which calls the direct call. The wrapper is auto-generated. Whether you consider the wrapper the "actual caller" depends on your point of view I guess.

You can avoid the wrappers by defining the methods on *fooMether instead of fooMether.

I'm not sure what to do about this in the mean time. We'll have to look at callers again when we look at non-leaf inlining this winter. Maybe then would be a good time to revisit the behavior of runtime.Caller with respect to eliding autogenerated wrappers.

/cc @aclements

@rsc rsc modified the milestones: Go1.9, Go1.8 Nov 11, 2016


This comment has been minimized.

Copy link

commented Jun 12, 2017

CL mentions this issue.


This comment has been minimized.

Copy link

commented Jun 12, 2017

CL mentions this issue.


This comment has been minimized.

Copy link

commented Jun 14, 2017

Bumping to Go 1.10 since this isn't a regression and there's some concern that this may affect code that's already compensating for this. The general consensus is that this should be fixed, however, so that the traceback APIs reflect the programmer's model of the stack rather than the implementation's model (like how the skip parameter now expands out inlined frames to match the programmer's model).

Early in the 1.10 cycle we should put in something like the CLs I posted above.

@aclements aclements modified the milestones: Go1.10, Go1.9 Jun 14, 2017

gopherbot pushed a commit that referenced this issue Sep 22, 2017

runtime: simplify stack walk in panicwrap
panicwrap currently uses runtime.Callers and runtime.CallersFrames to
find the name of its caller. Simplify this by using getcallerpc.

This will be important for #16723, since to fix that we're going to
make CallersFrames skip the wrapper method, which is exactly what
panicwrap needs to see.

Change-Id: Icb0776d399966e31595f3ee44f980290827e32a6
Run-TryBot: Austin Clements <>
TryBot-Result: Gobot Gobot <>
Reviewed-by: Ian Lance Taylor <>

@gopherbot gopherbot closed this in e972095 Sep 22, 2017

@golang golang locked and limited conversation to collaborators Sep 22, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.