See if this simpler example demonstrates the same problem:
https://play.golang.org/p/ZhkHnmq0ESg
May be related to this: #24488

EDIT: it seems that the line of the first occurrence of the method value is used, see:
https://play.golang.org/p/l2s2_gad56J

@pam4 Thanks; yes, your code describes the same problem.

This is interesting. Using gccgo does indeed log line 61. But using the gc compiler all the way back to 1.0.3 logs line 20.

CC @randall77 @josharian @griesemer @mdempsky

Shorter test case. The first line of output should show line 19, not line 15.

package main

import (
	"log"
	"os"
)

var lg = log.New(os.Stdout, "x: ", log.Lshortfile)

func main() {
	F()
}

func F() {
	defer lg.Println(trace(lg.Println))
}

func trace(f func(v ...interface{})) interface{} {
	f("calling")
	return "called"
}

Even shorter test case not even using log or defer

package main

import (
	"fmt"
	"runtime"
)

type foo struct{}

func (*foo) trace() {
	_, fileName, fileLine, _ := runtime.Caller(1)
	fmt.Println(fileName, fileLine)
}

func test(f func()) {
	f()
}

func main() {
	f := foo{}
	test(f.trace)
	test(f.trace)
	test(f.trace)
}

This issue is definitely a duplicate of #24488.

Also the title is misleading because there is nothing specific about defer or the log package (except for the fact that the log package makes use of stack information).

The problem is that method values end up in the stack trace, even though they are not function calls.

But oddly, the method value that ends up in the stack trace is not necessarily the one that leads to the function call; please take a look at this example: https://play.golang.org/p/RKQj5JcxvJH

I would prefer method values not to end up in the stack trace at all (unless they are actually called) because some of my code depends on it.

EDIT: the unexpected frames may represent compiler generated wrapper methods, see #16723.
The traceback API should reflect the programmer's model of the stack rather than the implementation's model.

Closing as dup.