x/telemetry/internal/mmap: TestSharedMemory failures

[gopherbot]

#!watchflakes
default <- pkg == "golang.org/x/telemetry/internal/mmap" && test == "TestSharedMemory"

Issue created automatically to collect these failures.

Example (log):

=== RUN   TestSharedMemory
    mmap_test.go:113: incremented 99 times, want 100
--- FAIL: TestSharedMemory (0.76s)

— watchflakes

[gopherbot]

Found new dashboard test flakes for:

#!watchflakes
default <- pkg == "golang.org/x/telemetry/internal/mmap" && test == "TestSharedMemory"

2024-11-06 14:24 x_telemetry-go1.22-netbsd-arm telemetry@58a11223 release-branch.go1.22@c19e5887 x/telemetry/internal/mmap.TestSharedMemory (log)

=== RUN TestSharedMemory mmap_test.go:113: incremented 99 times, want 100 --- FAIL: TestSharedMemory (0.76s)

— watchflakes

[findleyr]

@rsc @cherrymui between this and #68659, it looks like some of our assumptions about 64 bit atomics on mmapped memory do not hold, at least on netbsd-arm. (#68659 also has some flakes on Darwin, but let's focus on netbsd for now as #68659 is much higher level, and there may be something else going on).

This test is pretty low level, checking that after incrementing an atomic uint64 in mmapped memory shared by 100 subprocesses, we observe 100 ticks.

I will eventually dig into this, but if you have any intuition about this problem, or specific knowledge of limitations on bsds, it would be greatly appreciated.