runtime: invalid pc-encoded table f=sync/atomic.StoreUintptr

[mikioh]

See http://build.golang.org/log/ed507c93da11bd30cd9baedc88d06565456b267a.

##### ../misc/cgo/testcshared
runtime: invalid pc-encoded table f=sync/atomic.StoreUintptr pc=0x1000579e0 targetpc=0x1000590d0 tab=[0/0]0x0
    value=107 until pc=0x1000579e0
fatal error: invalid runtime symbol table
runtime: panic before malloc heap initialized

runtime stack:
runtime.throw(0x10008b9e0, 0x1c)
    /Volumes/ramdisk/gobuilder/darwin-amd64-4b2774f5ea4f/go/src/runtime/panic.go:527 +0x96 fp=0x100380c80 sp=0x100380c68
runtime.pcvalue(0x1000c20e0, 0x285cd, 0x1000590d0, 0x1, 0x0)
    /Volumes/ramdisk/gobuilder/darwin-amd64-4b2774f5ea4f/go/src/runtime/symtab.go:260 +0x379 fp=0x100380d28 sp=0x100380c80
runtime.moduledataverify1(0x1000c44e0)
    /Volumes/ramdisk/gobuilder/darwin-amd64-4b2774f5ea4f/go/src/runtime/symtab.go:142 +0x9a2 fp=0x100380e90 sp=0x100380d28
runtime.moduledataverify()
    /Volumes/ramdisk/gobuilder/darwin-amd64-4b2774f5ea4f/go/src/runtime/symtab.go:97 +0x32 fp=0x100380ea8 sp=0x100380e90
runtime.schedinit()
    /Volumes/ramdisk/gobuilder/darwin-amd64-4b2774f5ea4f/go/src/runtime/proc1.go:54 +0x5d fp=0x100380ef0 sp=0x100380ea8
runtime.rt0_go(0x7fff5fbff8e0, 0x1, 0x7fff5fbff8e0, 0x100380f50, 0x7fff88532fd6, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
    /Volumes/ramdisk/gobuilder/darwin-amd64-4b2774f5ea4f/go/src/runtime/asm_amd64.s:109 +0x135 fp=0x100380ef8 sp=0x100380ef0
FAIL test0 got 
2015/07/09 16:22:36 Failed: exit status 1

Looks like it's stable to reproduce from 4b2774f.

[ianlancetaylor]

CC @mwhudson

[ianlancetaylor]

Mikioh says says this bug occurs consistently since the sysmon change, so CC @aclements @RLH

[mwhudson]

Yeah, I looked at this very briefly but if it's that change that breaks things, I don't think it's in my area..

[randall77]

It looks like this is happening really early in initialization. I haven't looked at the test in particular, but the error message is informative. It's trying to look up a PC at ...90d0 in StoreUintptr. StoreUintptr starts at ...79e0, and StoreUintptr is only one instruction long. So the mapping from pc to functions is broken somehow. Given that StoreUintptr is the last function in its file (and its package?), we're probably not trying to look up that function at all, but some subsequent function that doesn't have a symtab entry. Or we're getting the wrong module for it.

[mwhudson]

That makes me think of #10747 but that was fixed quite a few days ago now.

[rsc]

The logic about checking the pcln table assumes that if you know the PC of the next entry in the table, the current entry has code up to about that point. In particular, it assumes the padding between the current entry and the next entry is no more than 16 bytes, because no Go architecture aligns functions to more than 16 bytes.

But if you're using the extra linking modes then foreign code chunks (.text sections from foreign .o files) end up in the text segment too, and they can have arbitrarily larger alignments. Perhaps that is what happened here. I will disable the test if the thing coming up is not Go code.

[gopherbot]

CL https://golang.org/cl/12550 mentions this issue.