cmd/link: cgo symbols can fall outside race detector mapped memory on darwin

[josharian]

package main

// int ii[65537];
import "C"

var sink C.int

func main() {
    for i := range C.ii {
        sink = C.ii[i]
    }
}

panics on darwin when run under race detector. The problem is that ii is not grouped with other bss symbols.

See https://groups.google.com/forum/#!topic/golang-dev/UVBznzrj5S4 for much more discussion.

Possible fixes include (1) somehow getting the linked symbols organized correctly and (2) teaching the race detector to find all C symbols.

I'll send a CL with a disabled failing test shortly. I'd love help fixing this. I'm not even sure where to start.

cc @crawshaw @ianlancetaylor @mwhudson @dvyukov

[gopherbot]

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

[aclements]

On ELF platforms, a program has runtime access to its own section table. If the same is true of Mach-O, we could consult that for the bounds of the C symbols.

[gopherbot]

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

[josharian]

When this is fixed, we should revert CL 29077.

[dvyukov]

@josharian can you provide a GOTRACEBACK=system and/or gdb/lldb stacks?

We filter out addresses without shadow memory:

func isvalidaddr(addr unsafe.Pointer) bool {
    return racearenastart <= uintptr(addr) && uintptr(addr) < racearenaend ||
        racedatastart <= uintptr(addr) && uintptr(addr) < racedataend
}

TEXT    racecalladdr<>(SB), NOSPLIT, $0-0
    get_tls(R12)
    MOVQ    g(R12), R14
    MOVQ    g_racectx(R14), RARG0   // goroutine context
    // Check that addr is within [arenastart, arenaend) or within [racedatastart, racedataend).
    CMPQ    RARG1, runtime·racearenastart(SB)
    JB  data
    CMPQ    RARG1, runtime·racearenaend(SB)
    JB  call
data:
    CMPQ    RARG1, runtime·racedatastart(SB)
    JB  ret
    CMPQ    RARG1, runtime·racedataend(SB)
    JAE ret

So I don't understand what tries to access these addresses.

[josharian]

I can no longer reproduce using the standalone snippet at the top of this issue. I'm not sure why. However, in misc/cgo/test, after removing the t.Skip in issue17065.go:

$ GOTRACEBACK=system go test -run=17065 -race
unexpected fault address 0x2000133cd180
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x2000133cd180 pc=0x41774bc]

goroutine 18 [running]:
runtime.throw(0x7fff5fbff440, 0x0)
    /Users/josh/go/tip/src/runtime/panic.go:596 +0x95 fp=0x7fff5fbff460 sp=0x7fff5fbff440
runtime.throw(0x1f, 0x0)
    /Users/josh/go/tip/src/runtime/panic.go:596 +0x95 fp=0x7fff5fbff480 sp=0x7fff5fbff460
created by testing.(*T).Run
    /Users/josh/go/tip/src/testing/testing.go:674 +0x535

goroutine 1 [chan receive]:
runtime.gopark(0x42254d8, 0xc4200a2298, 0x421ac2f, 0xc, 0xc42001f317, 0x3)
    /Users/josh/go/tip/src/runtime/proc.go:261 +0xfd fp=0xc420051a60 sp=0xc420051a30
runtime.goparkunlock(0xc4200a2298, 0x421ac2f, 0xc, 0x17, 0x3)
    /Users/josh/go/tip/src/runtime/proc.go:267 +0x5e fp=0xc420051aa0 sp=0xc420051a60
runtime.chanrecv(0x41ce7c0, 0xc4200a2240, 0x0, 0xc420051b01, 0x41248b5)
    /Users/josh/go/tip/src/runtime/chan.go:496 +0x1ed fp=0xc420051b20 sp=0xc420051aa0
runtime.chanrecv1(0x41ce7c0, 0xc4200a2240, 0x0)
    /Users/josh/go/tip/src/runtime/chan.go:378 +0x35 fp=0xc420051b58 sp=0xc420051b20
testing.(*T).Run(0xc4200c0000, 0x421a283, 0x9, 0x4222540, 0x4314301)
    /Users/josh/go/tip/src/testing/testing.go:675 +0x573 fp=0xc420051c48 sp=0xc420051b58
testing.runTests.func1(0xc4200c0000)
    /Users/josh/go/tip/src/testing/testing.go:830 +0xab fp=0xc420051ca0 sp=0xc420051c48
testing.tRunner(0xc4200c0000, 0xc420051d88)
    /Users/josh/go/tip/src/testing/testing.go:637 +0xca fp=0xc420051ce0 sp=0xc420051ca0
testing.runTests(0x42250d0, 0x4319c20, 0x43, 0x43, 0x40355ac)
    /Users/josh/go/tip/src/testing/testing.go:836 +0x4a5 fp=0xc420051db8 sp=0xc420051ce0
testing.(*M).Run(0xc420051ef0, 0x403b2ba)
    /Users/josh/go/tip/src/testing/testing.go:771 +0x130 fp=0xc420051e98 sp=0xc420051db8
main.main()
    _/Users/josh/go/tip/misc/cgo/test/_test/_testmain.go:188 +0x1b9 fp=0xc420051f50 sp=0xc420051e98
runtime.main()
    /Users/josh/go/tip/src/runtime/proc.go:185 +0x1a3 fp=0xc420051fa0 sp=0xc420051f50
runtime.goexit()
    /Users/josh/go/tip/src/runtime/asm_amd64.s:2160 +0x1 fp=0xc420051fa8 sp=0xc420051fa0

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /Users/josh/go/tip/src/runtime/asm_amd64.s:2160 +0x1 fp=0xc420040fb8 sp=0xc420040fb0

goroutine 2 [force gc (idle)]:
runtime.gopark(0x42254d8, 0x431f7d0, 0x421b4a2, 0xf, 0x402ec14, 0x1)
    /Users/josh/go/tip/src/runtime/proc.go:261 +0xfd fp=0xc42002c748 sp=0xc42002c718
runtime.goparkunlock(0x431f7d0, 0x421b4a2, 0xf, 0x14, 0x1)
    /Users/josh/go/tip/src/runtime/proc.go:267 +0x5e fp=0xc42002c788 sp=0xc42002c748
runtime.forcegchelper()
    /Users/josh/go/tip/src/runtime/proc.go:226 +0x9e fp=0xc42002c7c0 sp=0xc42002c788
runtime.goexit()
    /Users/josh/go/tip/src/runtime/asm_amd64.s:2160 +0x1 fp=0xc42002c7c8 sp=0xc42002c7c0
created by runtime.init.4
    /Users/josh/go/tip/src/runtime/proc.go:215 +0x35

goroutine 3 [GC sweep wait]:
runtime.gopark(0x42254d8, 0x431f9a0, 0x421ae7a, 0xd, 0x4021614, 0x1)
    /Users/josh/go/tip/src/runtime/proc.go:261 +0xfd fp=0xc42002cf38 sp=0xc42002cf08
runtime.goparkunlock(0x431f9a0, 0x421ae7a, 0xd, 0x14, 0x1)
    /Users/josh/go/tip/src/runtime/proc.go:267 +0x5e fp=0xc42002cf78 sp=0xc42002cf38
runtime.bgsweep(0xc42005c000)
    /Users/josh/go/tip/src/runtime/mgcsweep.go:63 +0xb6 fp=0xc42002cfb8 sp=0xc42002cf78
runtime.goexit()
    /Users/josh/go/tip/src/runtime/asm_amd64.s:2160 +0x1 fp=0xc42002cfc0 sp=0xc42002cfb8
created by runtime.gcenable
    /Users/josh/go/tip/src/runtime/mgc.go:213 +0x61

goroutine 4 [finalizer wait]:
runtime.gopark(0x42254d8, 0x4cecf68, 0x421b198, 0xe, 0x14, 0x1)
    /Users/josh/go/tip/src/runtime/proc.go:261 +0xfd fp=0xc42002d708 sp=0xc42002d6d8
runtime.goparkunlock(0x4cecf68, 0x421b198, 0xe, 0x14, 0x1)
    /Users/josh/go/tip/src/runtime/proc.go:267 +0x5e fp=0xc42002d748 sp=0xc42002d708
runtime.runfinq()
    /Users/josh/go/tip/src/runtime/mfinal.go:161 +0xaf fp=0xc42002d7c0 sp=0xc42002d748
runtime.goexit()
    /Users/josh/go/tip/src/runtime/asm_amd64.s:2160 +0x1 fp=0xc42002d7c8 sp=0xc42002d7c0
created by runtime.createfing
    /Users/josh/go/tip/src/runtime/mfinal.go:142 +0x62

goroutine 5 [syscall]:
runtime.notetsleepg(0x4ced1a0, 0xffffffffffffffff, 0x0)
    /Users/josh/go/tip/src/runtime/lock_sema.go:257 +0x4b fp=0xc42002df60 sp=0xc42002df20
os/signal.signal_recv(0x405ba71)
    /Users/josh/go/tip/src/runtime/sigqueue.go:116 +0x104 fp=0xc42002df88 sp=0xc42002df60
os/signal.loop()
    /Users/josh/go/tip/src/os/signal/signal_unix.go:22 +0x30 fp=0xc42002dfc0 sp=0xc42002df88
runtime.goexit()
    /Users/josh/go/tip/src/runtime/asm_amd64.s:2160 +0x1 fp=0xc42002dfc8 sp=0xc42002dfc0
created by os/signal.init.1
    /Users/josh/go/tip/src/os/signal/signal_unix.go:28 +0x4f

goroutine 6 [syscall, locked to thread]:
runtime.cgocall(0x41a3d60, 0xc42002e7b0, 0x0)
    /Users/josh/go/tip/src/runtime/cgocall.go:130 +0x8b fp=0xc42002e770 sp=0xc42002e738
_/Users/josh/go/tip/misc/cgo/test._Cfunc_usleep(0xc400002710, 0x0)
    _/Users/josh/go/tip/misc/cgo/test/_test/_obj_test/_cgo_gotypes.go:1746 +0x6b fp=0xc42002e7b0 sp=0xc42002e770
runtime.goexit()
    /Users/josh/go/tip/src/runtime/asm_amd64.s:2160 +0x1 fp=0xc42002e7b8 sp=0xc42002e7b0
created by _/Users/josh/go/tip/misc/cgo/test.lockOSThreadCallback
    /Users/josh/go/tip/misc/cgo/test/issue3775.go:37 +0x55
FAIL    _/Users/josh/go/tip/misc/cgo/test   0.099s

I remember from previous debugging that the crash is from within tsan_read, called as part of reading the contents of the C array.

[rsc]

golang.org/cl/31824 for the fix.

@dvyukov, I can't find the source code to __tsan_map_shadow. I checked out github.com/llvm-mirror/llvm and cannot find that string anywhere in the checked out files. For future reference, where is it? Thanks.

[gopherbot]

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