False positives with iter.Pull and stdlib sync primitives

[kolkov]

Problem

Our detector reports false positive races when user code uses iter.Pull (Go 1.23+) or other stdlib functions that use internal synchronization via internal/race.Acquire/Release.

Root Cause

1. We only instrument user code via AST transformation
2. Go stdlib is pre-compiled - we don't instrument it
3. iter.Pull uses race.Acquire/Release for internal sync between caller and iterator goroutine
4. Our detector doesn't see these sync calls → reports false positives

Example

// iter/iter.go (Go stdlib):
func Pull[V any](seq Seq[V]) (next func() (V, bool), stop func()) {
    var pull struct {
        racer int  // sync variable
    }
    c := newcoro(func(c *coro) {
        race.Acquire(unsafe.Pointer(&pull.racer))  // SYNC!
        yield := func(v1 V) bool {
            race.Release(unsafe.Pointer(&pull.racer))  // SYNC!
            coroswitch(c)
            race.Acquire(unsafe.Pointer(&pull.racer))  // SYNC!
            return !pull.done
        }
    })
}

Evidence

Testing on zygomys (uses iter.Pull):

Detector	GOMAXPROCS=8, count=100	Result
TSAN	100 runs	PASS - no races
Ours	5 runs	FAIL - multiple "races"

TSAN correctly sees the happens-before from iter.Pull. Our detector does not.

Affected stdlib functions

• iter.Pull / iter.Pull2 (Go 1.23+)
• Potentially any stdlib using internal/race.Acquire/Release

Possible Solutions

Short-term (P1):

1. Document limitation in README/docs
2. Filter reports involving iter.Pull goroutines (heuristic)
3. Warn users when iter.Pull detected in stack trace

Long-term (P2):

1. Intercept stdlib sync - Hook into runtime sync primitives
2. Compiler integration - Like TSAN, get sync info from compiler
3. Hybrid approach - Combine with -race flag for stdlib coverage

Related

• Research report: docs/dev/research-reports/ZYGOMYS_RACE_INVESTIGATION.md
• runtime/race: eliminate dependency on cmd/cgo golang/go#6508 (our comment may need correction)
• Issue [BUG] false positive races found, only half of a race is reported (previous access stack trace not available) #17 (original zygomys report from @glycerine)

Priority

P1 - This affects correctness. False positives reduce trust in the tool.