ReviewOS

zig-utils/zig-js

Fuzz: diagnose deterministic amplify seed 107 timeout under TSan

#103
Closed chris opened this 9 days ago ·
9 days ago

Problem

The high-contention ThreadSanitizer fuzzer deterministically exceeded its former 120-second per-seed timeout for amplify seed 107. The abrupt timeout abort then caused TSan to report the still-running worker threads as leaks.

This reproduced on the untouched e4b72407 parent and on the per-chunk free-bitmap candidate for #102, so it was pre-existing and independent of that allocator change.

Reproduction

zig build threadfuzz -Dtsan=true -Dfuzz-iters=1 -Dfuzz-seed=107 -Dfuzz-amplify=true

Resolution

Resolved by 1221a46b.

The exact seed is sanitizer workload slowness, not deadlock or livelock:

  • normal build: 2,406 ms fuzzer wall time, zero failures
  • TSan build with a 300,000 ms diagnostic window: 177,219 ms fuzzer wall time, zero failures and no race
  • therefore amplified TSan runs now default to a calibrated 300,000 ms per-seed window unless THREADFUZZ_SEED_TIMEOUT_MS explicitly overrides it

Timeout handling no longer immediately exits with live workers. The watchdog requests allocation-free cooperative termination from the active Context, the evaluation unwinds, Context.destroy() joins the shared-realm threads, and only then does the harness report status 124. A separate 30-second cleanup grace force-aborts with status 125 if teardown itself is stuck.

The bounded deterministic CI regression intentionally interrupts the same seed after one second:

THREADFUZZ_SEED_TIMEOUT_MS=1000 THREADFUZZ_EXPECT_TIMEOUT=1 zig build threadfuzz -Dtsan=true -Dfuzz-amplify=true -Dfuzz-iters=1 -Dfuzz-seed=107

It passed locally under TSan with the expected timeout, clean context teardown, and no secondary leak report. The focused host-termination unit also passed under both normal and TSan builds. README, thread testing documentation, and required CI are updated in the same commit.

Acceptance criteria

  • Determine whether seed 107 is a deadlock/livelock or simply exceeds the TSan timeout due to workload size.
  • Add a bounded deterministic regression that distinguishes progress from a hang.
  • Ensure timeout cleanup joins/terminates worker threads without a secondary TSan leak report.
  • Pass the isolated seed and the amplify TSan profile.

Related: #102

Sign in to comment on this issue.