package main

/*
   int v[8192];
*/
import "C"
import "fmt"

var x [8192]C.int

func main() {
	fmt.Printf("&x[0]=%p &x[len-1]=%p &v[0]=%p &v[len-1]=%p\n", &x[0], &x[len(x)-1], &C.v[0], &C.v[len(C.v)-1])
	copy(C.v[:], x[:])
}

This program crashes when run with

go run -race reproducer.go

on either darwin/arm64 or windows/amd64. Possibly others.
It does not reproduce on linux/amd64.

For debugging, it helps to add this to the runtime:

--- a/src/runtime/race.go
+++ b/src/runtime/race.go
@@ -486,6 +486,7 @@ func raceinit() (gctx, pctx uintptr) {
        racecall(&__tsan_map_shadow, start, size, 0, 0)
        racedatastart = start
        racedataend = start + size
+       println("racedata", hex(start), hex(start+size))
 
        return
 }

The bug occurs because the large C array straddles what the race detector considers the data section. The start of the C array is in the data section, but the tail of it is outside the data section. The race detector doesn't allocate shadow stack for that region, and barfs (and, does not barf nicely).

The race detector attempts to ignore C memory by checking if the starting address of the region being read/written is inside the data section. But it does not check the end address, so large regions can fool this check when the start is in but the end is out (and out enough to reach a page boundary or whatever chunking the race detector does).

The bounds checking is done in runtime/race_*.s:racecalladdr. Fixing that check to properly check the high end of the range seems to fix things. Not entirely sure if that is the right fix, or should we instead extract the right racedata start/end to include the whole data section? Including all the C static data shouldn't hurt, and it might help.

@dvyukov @cuonglm