The failure path of the lock-free `__atomic_compare_exchange*` helpers re-reads `*ptr` in a **separate, later** step instead of reporting the value observed during the failed comparison. If `*ptr` transiently reverts to `old` inside that window, the function writes `old` back into `*expected` and returns 0 - i.e. it reports *failure* while handing back the value that means *"the swap succeeded"*. This silently breaks the ubiquitous C spin idiom ```c while (atomic_compare_exchange_strong(&lock, &zero, 1) != 0) ; /* acquire */ ``` Callers fall out of the loop **without owning the lock**. Every subsequent mutual-exclusion assumption is then void. Not platform-specific: `stdatomic.go` has no build tags. Reproduced on linux/amd64 and linux/386. ## Affected * `modernc.org/libc` - observed on **v1.74.1**, code unchanged at least since v1.72.x * File: `stdatomic.go` * Functions: `X__atomic_compare_exchangeInt32`, `X__atomic_compare_exchangeUint32`, `X__atomic_compare_exchangeInt64`, `X__atomic_compare_exchangeUint64` Not affected (correct - they read the witness under the same mutex that guards the compare): `X__atomic_compare_exchangeInt8/Int16` and the whole `X__c11_atomic_compare_exchange_strong*` family. ## Root cause ```go func X__atomic_compare_exchangeUint64(t *TLS, ptr, expected, desired uintptr, weak, success, failure int32) int32 { p := (*uint64)(unsafe.Pointer(ptr)) exp := (*uint64)(unsafe.Pointer(expected)) des := *(*uint64)(unsafe.Pointer(desired)) old := *exp if atomic.CompareAndSwapUint64(p, old, des) { return 1 } *exp = atomic.LoadUint64(p) // <-- separate load, NOT the failure witness return 0 } ``` The CAS and the witness-load are two independent atomic operations with a gap between them. ## Why this is a contract violation C11 §7.17.7.4 (`atomic_compare_exchange_strong`): > **Atomically**, compares the value pointed to by `object` for equality with that > in `expected`, and if true, replaces the value pointed to by `object` with > `desired`, **and if false, updates the value in `expected` with the value pointed > to by `object`**. […] These operations are atomic read-modify-write operations. The update of `expected` on failure is *inside* the atomic operation. Hardware does exactly this: `cmpxchg` / `cmpxchg8b` load the actual value into the accumulator as part of the same instruction. A later, separate re-read is not equivalent. The practical invariant callers rely on, and which is currently broken: > **return 0 (failure) ⟹ `*expected != old`** ## Minimal reproducer (no C, no ccgo) ```go package main import ( "fmt" "sync/atomic" "unsafe" "modernc.org/libc" ) var ( word uint64 des uint64 = 1 ) const seqCst = 5 // __ATOMIC_SEQ_CST func main() { pw := uintptr(unsafe.Pointer(&word)) pd := uintptr(unsafe.Pointer(&des)) exp := new(uint64) stop := make(chan struct{}) done := make(chan struct{}) // A concurrent owner that takes the lock and then releases it. go func() { defer close(done) for { select { case <-stop: return default: } atomic.StoreUint64(&word, 1) atomic.StoreUint64(&word, 0) } }() const N = 20_000_000 violations := 0 for i := 0; i < N; i++ { *exp = 0 r := libc.X__atomic_compare_exchangeUint64(nil, pw, uintptr(unsafe.Pointer(exp)), pd, 0, seqCst, seqCst) if r == 0 && *exp == 0 { // Reported failure, but handed back the expected value. // `while (cas(p,0,1) != 0);` would exit here without the lock. violations++ } } close(stop) <-done fmt.Printf("iterations=%d violations=%d\n", N, violations) } ``` Result on linux/amd64, go1.23, libc v1.74.1 (it is a race, so the count varies between runs - observed 93815 and 187391 on two runs, i.e. roughly 0.5–1% of attempts): ``` iterations=20000000 violations=187391 ``` With the patch below: `violations=0`, reproducibly. Also reproduced on linux/386. ## Real-world impact Found while diagnosing `modernc.org/libquickjs` CI builders that wedge at 100% CPU for 19+ hours and only pass on a later run. test262's `$262.agent` helpers use exactly the spin idiom above. In `built-ins/Atomics/wait/{,bigint/}waiterlist-order-of-operations-is-fifo.js`: 1. agent C's `CAS(LOCK, 0n, 1n)` fails - agent B holds the lock; 2. the main thread runs `Atomics.store(i64a, LOCK_INDEX, 0n)` (its release for B); 3. agent C's late re-read now returns `0`, so `Atomics.compareExchange` returns `0n` and C's spin loop exits **believing it acquired** - `LOCK` is still `0`; 4. C parks in `Atomics.wait`; the main thread spins forever in `$262.agent.waitUntil(i64a, LOCK_INDEX, 1n)` (a bare `do/while`, no timeout). Confirmed against a live hung process (gdb): main in `js_atomics_op` with `op == ATOMICS_OP_LOAD` on `LOCK_INDEX`, all three agents parked in `js_atomics_wait`, and the SharedArrayBuffer reading `WAIT=0, RUNNING=3, LOCK=0` - lock free, every agent already past it, nobody left to ever set it. Hang rates on a 2-CPU linux/386 box, single test, 200 runs each: | test | stock v1.74.1 | patched | | --- | --- | --- | | `Atomics/wait/bigint/waiterlist-order-of-operations-is-fifo.js` (Uint64) | 20/200 | **0/200** | | `Atomics/wait/waiterlist-order-of-operations-is-fifo.js` (Uint32) | 16/200 | **0/200** | Full `built-ins/Atomics` tree with the patch: 562 tests, 0 errors. ## Proposed fix Restore the invariant *return 0 ⟹ `*expected != old`* by retrying while the observed value is still `old` (a strong CAS that failed against `old` means `*p != old` at that instant, so a witness equal to `old` is never a valid failure report): ```diff func X__atomic_compare_exchangeUint64(t *TLS, ptr, expected, desired uintptr, weak, success, failure int32) int32 { p := (*uint64)(unsafe.Pointer(ptr)) exp := (*uint64)(unsafe.Pointer(expected)) des := *(*uint64)(unsafe.Pointer(desired)) old := *exp - if atomic.CompareAndSwapUint64(p, old, des) { - return 1 + for { + if atomic.CompareAndSwapUint64(p, old, des) { + return 1 + } + cur := atomic.LoadUint64(p) + if cur != old { + *exp = cur + return 0 + } } - *exp = atomic.LoadUint64(p) - return 0 } ``` and identically for `Int32`, `Uint32`, `Int64`. Notes on the fix: * If `cur == old` the value reverted between the failed CAS and the reload; a real `cmpxchg` issued at that moment would have **succeeded**, so retrying is strictly more faithful than reporting a witness that means "you won". * The loop only spins while another thread is actively flipping the word back to `old`; it makes progress on any interleaving where the value settles. * `weak != 0` (`compare_exchange_weak`) is permitted to fail spuriously, so it could return early without the retry. Treating it as strong is still conforming, and is what the code already does today. * An alternative is to mirror the `Int8`/`Int16` approach and take a mutex, but that would not interoperate with the lock-free `sync/atomic` accesses these helpers otherwise use. ## Relation to #51 Distinct defect, same class (an emulation of a synchronization primitive that is not atomic where the contract requires it). #51 is `___lock`/`___unlock`; nothing was parked in `___lock` in the hangs analysed here. Filing separately.