This is a result of eliding wrapper functions in tracebacks.

There's a wrapper function main.(*Handlers).Log which is required for the interface call. That function used to be reported in 1.11 and is no longer reported in 1.12.

Upgrading your example to print all the skips:

package main

import (
	"fmt"
	"runtime"
	"strconv"
	"strings"
)

type Handler interface {
	Log()
}

// Handlers a bundle for hander with filter function.
type Handlers struct{}

var h Handler = Handlers{}

// funcName get func name.
func funcName(skip int) (name string) {
	for i := 0; true; i++ {
		_, file, line, ok := runtime.Caller(i) // line 22
		if !ok {
			break
		}
		fmt.Printf("%d %s:%d\n", i, file[strings.LastIndex(file, "/")+1:], line)
	}
	if _, file, lineNo, ok := runtime.Caller(skip); ok {
		return file[strings.LastIndex(file, "/")+1:] + ":" + strconv.Itoa(lineNo)
	}
	return "unknown:0"
}

// Log handlers logging.
func (hs Handlers) Log() {
	println(funcName(4)) // line 36
}

func Error() {
	h.Log() // line 40
}

func main() {
	Error() // line 44
}

If you look at all the locations reported for different skips, in 1.11 you get:

0 issue31185.go:22
1 issue31185.go:36
2 issue31185.go:40
3 issue31185.go:44
4 issue31185.go:44
5 proc.go:201
6 asm_amd64.s:1333
issue31185.go:44

Notice the duplicate :44. One of those is for the call to the wrapper function main.(*Handlers).Log and one of those is for the call from the wrapper function to the user's function main.Handlers.Log.

From the user's perspective, though, the duplicate :44 is nonsense. What called itself at line 44? There's only one call there. To avoid this confusion, we decided to remove all the wrapper functions from tracebacks because their existence is implicit - there's no callsite to point to in the user's code where wrapper calls happened.

In 1.12, you get:

0 issue31185.go:22
1 issue31185.go:36
2 issue31185.go:40
3 issue31185.go:44
4 proc.go:200
5 asm_amd64.s:1337
proc.go:200

Which correctly corresponds to the callsites present in the user's code.

Thanks. This behavior change was mentioned in the release notes: https://golang.org/doc/go1.12#runtime

Closing for now given that @randall77 has provided a solution for you that takes the new behavior into account.