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

Closed
laboger opened this issue May 22, 2018 · 3 comments

Comments

Projects
None yet
4 participants
@laboger
Copy link
Contributor

commented May 22, 2018

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

This comment has been minimized.

Copy link
Member

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

@aclements

This comment has been minimized.

Copy link
Member

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

@gopherbot

This comment has been minimized.

Copy link

commented May 22, 2018

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

@gopherbot gopherbot closed this in e391fad May 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.