TL;DR
Get the latest gadgets delivered free with Prime
- Fast, free delivery on millions of items
- Prime Video, Amazon Music and more included
- Member-only deals all year
Farid Zakaria describes how Nix provides much of the foundation for Rewind VM, a deterministic virtual machine and debugging tool for reproducing race conditions in Nix builds. In a bank-account example, the tool identifies a schedule change at step 3237 that separates a passing run from a failing one; Zakaria reports the check took 11 seconds on his laptop.
Farid Zakaria says Nix provides much of the foundation for Rewind VM, a deterministic virtual machine and debugger he has been using to reproduce and investigate race conditions in Nix builds. In a report published October 7, he describes how Nix’s record of build inputs and access to program sources and debug symbols support features that let users compare runs and inspect a failure at a particular execution step.
Zakaria’s example is a small bank-account program in which two teller threads deposit money. Each thread reads a balance, writes a ledger line, then stores an updated balance. If one thread runs between another’s read and write, it can overwrite a newer balance with a value based on stale information. In Zakaria’s test, the program lost money in 396 of 1,000 runs on his 16-core laptop. Pinned to one core with taskset, it lost money in none of 1,000 runs.
Rewind VM runs with one virtual CPU, so the first run may not trigger the issue. Its rewind check command then repeats the build under altered thread schedules. For the example, Zakaria says it found that the passing and failing runs diverged at step 3237, when a reschedule in the failing run changed what happened. The check took 11 seconds on his laptop. That timing is Zakaria’s result for this example, not a general benchmark.
The tool also provides a source panel, stack frames, bookmarks, a comparison view and thread lanes, according to the report. With rewind gdb, users can open a debugger against a fork of a recorded run at the current step, inspect threads and program state, and use breakpoints or watchpoints. Zakaria says debugger actions do not alter the original recording, allowing users to return to a step and inspect it again.
How Nix Supports Debugging
The report’s central point is that a debugger’s difficult work is not limited to showing source code or stopping at a breakpoint. To reproduce a problem elsewhere, a user needs the program’s exact inputs, its compiler and libraries, relevant kernel and virtual-machine settings, and matching source and debug information. Zakaria argues that Nix already tracks many of those ingredients as part of a derivation, making it possible for Rewind to build a reproducible environment around a debugging session.
That connection matters to developers investigating intermittent concurrency bugs. A race may disappear when a program is rerun, moved to another machine or inspected with different tools. Rewind’s schedule perturbation and step-by-step comparison are intended to make the difference between two executions easier to locate. Nix’s role, as Zakaria describes it, is to make the underlying program and its environment repeatable enough for those comparisons to be useful.
The report is also an account of one developer’s tool and experience, rather than an independent evaluation. It explains a technical approach and gives one test result, but does not establish how well Rewind performs across other workloads or systems.
Products Worth Considering
Bose SoundLink Flex Bluetooth Speaker (2nd Gen), Black
Bose SoundLink Max Bluetooth Speaker
Jackery Solar Generator 1000 v2 with 200W Solar Panel
As an affiliate, we earn on qualifying purchases.
Derivations as Debugging Inputs
A Nix derivation describes how to build a package and records its inputs. Zakaria says Rewind can accept a derivation or a flake reference, realise the derivation’s inputs, package the resulting closure into a read-only EROFS image and boot a virtual machine from it. Those inputs can include the source code, compiler, libraries, kernel and VM configuration. Rewind identifies a run with a hash of its inputs and can print the command used to reproduce it.
Zakaria also says Nixpkgs packages are built with separate debug information, which is available through the NixOS binary cache. Rewind uses debuginfod to retrieve debug information and source by build ID, including source for binaries such as the Linux kernel. The report says a successful guest run reports output NAR hashes, which Rewind checks against the host store and binary-cache metadata. These mechanisms are the basis for the author’s claim that Nix supplies parts of the debugger’s infrastructure rather than merely serving as a package manager.
“The hard part of each feature was already done, and Nix had done it.”
— Farid Zakaria, in his October 7, 2026 report
What the Report Does Not Establish
The report does not provide independent testing, a broad performance evaluation or results across different applications and hardware. The 396 failures in 1,000 runs and the 11-second check time concern Zakaria’s bank-program example on his laptop; the report does not establish how often other races will be found or how long their checks will take.
It is also unclear from the provided report how Rewind handles programs whose builds or behavior depend on inputs not captured by the derivation, or how its workflow performs on larger projects. The article describes features and the author’s own use of the tool, but does not include outside assessments or user adoption figures. Those limits matter when judging the broader claims suggested by the title: the report explains why Nix helped build this debugger, not that every debugger can obtain half its functionality from Nix.
Further Tests Will Show Its Reach
Zakaria’s report does not announce a release date, adoption target or formal evaluation plan. The immediate next step for readers seeking to assess the approach is to inspect the project and try its documented commands on suitable Nix derivations, while treating the bank example as a demonstration rather than a general performance guarantee.
Further reports or independent tests could clarify how often schedule perturbation exposes real races, how Rewind scales to larger builds and whether the same reproducibility holds across different machines. Until then, the confirmed development is a technical report describing a working set of Rewind VM features and the Nix capabilities its author says made them easier to build.
Key Questions
What is Rewind VM?
Rewind VM is a virtual-machine and debugging tool described by Farid Zakaria. It runs builds in a controlled environment and can repeat them with perturbed thread schedules to help investigate race conditions.
What does Nix contribute to the debugger?
Zakaria says Nix makes it easier to identify and reproduce a derivation’s build inputs, while Nixpkgs and debuginfod provide access to debug information and source files. Rewind uses these capabilities as part of its reproducible debugging workflow.
What did the bank-account test find?
In Zakaria’s example, the program lost money in 396 of 1,000 runs on a 16-core laptop and none of 1,000 runs when pinned to one core. Rewind identified step 3237 as the point where a reschedule separated a passing run from a failing one.
Does the report prove Rewind works for every race condition?
No. The report gives one author-described example and does not provide independent evaluations or results across a range of applications. Its broader performance and applicability remain unclear.
Source: hn
