runtime: panic when using errors.As with validation errors from github.com/go-ozzo/ozzo-validation

[jonbodner]

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

$ go version
1.13.4 (also replicated on the Go Playground)

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="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jon/.cache/go-build"
GOENV="/home/jon/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jon/go"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go-1.13.4"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go-1.13.4/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build748483515=/tmp/go-build -gno-record-gcc-switches"

What did you do?

https://play.golang.org/p/VytvF2r_qhO

What did you expect to see?

print out no bug

What did you see instead?

panic:

=== RUN TestBug
runtime: nameOff 0xe90983b out of range 0x140000 - 0x1c642f
fatal error: runtime: name offset out of range

goroutine 6 [running]:
runtime.throw(0x1776e6, 0x21)
/usr/local/go/src/runtime/panic.go:774 +0x80 fp=0x41a5b0 sp=0x41a590 pc=0x56b20
runtime.resolveNameOff(0x163d80, 0xe90983b, 0x141db0, 0x76c)
/usr/local/go/src/runtime/type.go:190 +0x480 fp=0x41a5f8 sp=0x41a5b0 pc=0x87620
internal/reflectlite.resolveNameOff(0x163d80, 0xe90983b, 0x141db0, 0x76c)
/usr/local/go/src/runtime/runtime1.go:497 +0x40 fp=0x41a610 sp=0x41a5f8 pc=0x6d060
internal/reflectlite.(*rtype).nameOff(...)
/usr/local/go/src/internal/reflectlite/type.go:416
internal/reflectlite.implements(0x157720, 0x163d80, 0x267500, 0x3ca0)
/usr/local/go/src/internal/reflectlite/type.go:749 +0x5a0 fp=0x41a6b8 sp=0x41a610 pc=0x9ac40
internal/reflectlite.(*rtype).AssignableTo(0x163d80, 0x1c43c0, 0x157720, 0x157720, 0xfefc0008, 0x0)
/usr/local/go/src/internal/reflectlite/type.go:680 +0xa0 fp=0x41a6d0 sp=0x41a6b8 pc=0x9a5c0
errors.As(0x1c3490, 0x43e640, 0x14adc0, 0x40c230, 0x4af9f070, 0x0)
/usr/local/go/src/errors/wrap.go:80 +0x2a0 fp=0x41a738 sp=0x41a6d0 pc=0x9e780
main.TestBug(0x4680b0, 0xbab699fc)
/tmp/sandbox550226823/prog.go:16 +0x80 fp=0x41a778 sp=0x41a738 pc=0x13bc40
testing.tRunner(0x4680b0, 0x1a92ac)
/usr/local/go/src/testing/testing.go:909 +0x120 fp=0x41a7d8 sp=0x41a778 pc=0x11fb40
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64p32.s:523 +0x1 fp=0x41a7e0 sp=0x41a7d8 pc=0x921c1
created by testing.(*T).Run
/usr/local/go/src/testing/testing.go:960 +0x3c0

goroutine 1 [chan receive]:
testing.(*T).Run(0x4680b0, 0x17212d, 0x7, 0x1a92ac, 0x4af9f070, 0x0)
/usr/local/go/src/testing/testing.go:961 +0x400
testing.runTests.func1(0x468000, 0xbab699fc)
/usr/local/go/src/testing/testing.go:1202 +0x80
testing.tRunner(0x468000, 0x45aea8)
/usr/local/go/src/testing/testing.go:909 +0x120
testing.runTests(0x40a0f0, 0x40a0e0, 0x1, 0x1, 0x0, 0x0)
/usr/local/go/src/testing/testing.go:1200 +0x2e0
testing.(*M).Run(0x432100, 0x159120, 0x0, 0x5)
/usr/local/go/src/testing/testing.go:1117 +0x200
testing.Main(0x1a92b0, 0x40a0e0, 0x1, 0x1, 0x0, 0x0, 0x0, 0x277ca4, 0x0, 0x0)
/usr/local/go/src/testing/testing.go:1044 +0x120
main.main()
/tmp/sandbox550226823/prog.go:30 +0xe0

[ianlancetaylor]

I can replicate the problem with Go 1.13 but not with tip.

[ianlancetaylor]

On tip the problem was fixed by https://golang.org/cl/191198 == 36f30ba, so the fix may have been coincidental.

[ianlancetaylor]

Self contained test case. Crashes with 1.13, passes with tip.

package main

import (
	"errors"
)

type I map[string] error

func (i I) Error() string {
	return ""
}

func main() {
	e := I{}
	var x interface {
		error
		M123() // works if this is named M12
	}
	errors.As(e, &x)
}

[ianlancetaylor]

OK, this is a dup of #34486.

We should fix this for 1.13.

[ianlancetaylor]

Note that the fix in #34486 won't cherry pick, because it reflects other changes made to tip.

[cuonglm]

Note that the fix in #34486 won't cherry pick, because it reflects other changes made to tip.

Hi Ian, so how should we fix this?

[ianlancetaylor]

I just sent https://golang.org/cl/205721.