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: invalid pc-encoded table error beginning with commit ed7a068 on ppc64x, s390x, arm64 #25499

laboger opened this issue May 22, 2018 · 3 comments


Copy link

@laboger laboger commented May 22, 2018

Please answer these questions before submitting your issue. Thanks!

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


Does this issue reproduce with the latest release?


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


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
/workdir/go/src/runtime/stack.go:1013 +0x24c
/workdir/go/src/runtime/asm_arm64.s:298 +0x68

Copy link

@mundaym mundaym commented May 22, 2018

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.

@mundaym mundaym added this to the Go1.11 milestone May 22, 2018
@mundaym mundaym assigned mundaym and aclements and unassigned mundaym May 22, 2018
Copy link

@aclements aclements commented May 22, 2018

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. :)

Copy link

@gopherbot gopherbot commented May 22, 2018

Change mentions this issue: runtime: fix defer matching of leaf functions on LR machines

@gopherbot gopherbot closed this in e391fad May 22, 2018
@golang golang locked and limited conversation to collaborators May 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.