runtime: invalid pc-encoded table error beginning with commit ed7a068 on ppc64x, s390x, arm64

[laboger]

Please answer these questions before submitting your issue. Thanks!

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

tip

Does this issue reproduce with the latest release?

yes

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

ppc64le

What did you do?

I was notified of this error by our team building Docker with upstream golang, so went to the golang build page and saw that the same error was appearing there.

What did you expect to see?

No failures in the ppc64 or ppc64le columns of the build page.

What did you see instead?

Failure when running the sync/atomic test, same failure and stack appears for ppc64, ppc64le, s390x, arm64, maybe others but those are the ones I looked at.

runtime: invalid pc-encoded table f=sync/atomic_test.TestNilDeref.func1 pc=0xeab60 targetpc=0xeaf17 tab=[0/0]0x0
value=0 until pc=0xeab50
value=-2 until pc=0xeab60
fatal error: invalid runtime symbol table

runtime stack:
runtime.throw(0x13db68, 0x1c)
/workdir/go/src/runtime/panic.go:589 +0x48
runtime.pcvalue(0x1e1ba8, 0x1f5a40, 0x89c58, 0xeaf17, 0xfffff4abada8, 0x60001, 0x1)
/workdir/go/src/runtime/symtab.go:788 +0x40c
runtime.pcdatavalue(0x1e1ba8, 0x1f5a40, 0x0, 0xeaf17, 0xfffff4abada8, 0x1)
/workdir/go/src/runtime/symtab.go:852 +0x78
runtime.getStackMap(0xfffff4abaca8, 0xfffff4abada8, 0xffff00089c01, 0xeab38, 0xfffff4abab10, 0x1, 0x0)
/workdir/go/src/runtime/stack.go:1153 +0x1f4
runtime.adjustframe(0xfffff4abaca8, 0xfffff4abad90, 0x1f5a40)
/workdir/go/src/runtime/stack.go:624 +0x5c
runtime.gentraceback(0xffffffffffffffff, 0xffffffffffffffff, 0x0, 0x4000001200, 0x0, 0x0, 0x7fffffff, 0x142320, 0xfffff4abad90, 0x0, ...)
/workdir/go/src/runtime/traceback.go:318 +0xe50
runtime.copystack(0x4000001200, 0x1000, 0x170f01)
/workdir/go/src/runtime/stack.go:841 +0x1b4
runtime.newstack()
/workdir/go/src/runtime/stack.go:1013 +0x24c
runtime.morestack()
/workdir/go/src/runtime/asm_arm64.s:298 +0x68

[mundaym]

Are you already looking at this @aclements?

TestNilDeref calls the atomic functions indirectly so they won't be intrinsics. Not sure if that is relevant or not.

[aclements]

I'm on it and I have a fix. I'm testing it now (but about to go to lunch). This bug has actually been there for years. I promise the commit message will be an entertaining slog through runtime subtleties. :)

[gopherbot]

Change https://golang.org/cl/114078 mentions this issue: runtime: fix defer matching of leaf functions on LR machines