Nix wrote half of my debugger

A deterministic VM called Rewind, integrated with Nix, turns a Nix derivation into a fully reproducible, inspectable run so race conditions can be found, reproduced and fixed quickly. Because Nix already records every input (sources, compiler, libraries, kernel and VM config) and stores debug symbols and sources via separateDebugInfo and debuginfod, Rewind can pack a derivation into a read-only image, boot it, and produce a run whose id is a hash of its inputs. Using a simple banking example where two teller threads cause a lost-update on a 16-core laptop (396 failures out of 1,000 runs; zero when pinned to one core), Rewind perturbs schedules, narrows the first failing step to 3237 in about 11 seconds, and validates outputs by comparing NAR hashes against caches.

Rewind builds a GUI and CLI debugger on top of that reproducibility: a source panel and stack frames, a Compare view that highlights the first divergent event, thread lanes that show which thread held the CPU at each step, and non-destructive forks that let gdb attach to any playhead to set breakpoints/watchpoints and inspect memory. “Check from here” forks a run at any step and runs many schedules to measure how often an interleaving fails (example: forking at step 3221 produced 16 of 16 failing schedules). The core claim is concrete: starting from hermetic Nix derivations supplies most of a debugger’s hard parts, so Rewind only needs a modest layer to become a powerful race-finding tool.