Nixがデバッガーのコードをほぼ半分書いた
原題: Nix wrote half of my debugger
なぜ重要か
Nixの再現性モデルをデバッガー基盤として流用するアプローチは、再現困難なレースコンディション調査のコストを大幅に下げる可能性を示している。
エンジニアのFarid Zakaria氏は2026年10月7日、Nixビルドを決定論的VMで再現する「Rewind VM」の開発を通じ、デバッガー実装に必要な「入力の特定・デバッグシンボル・ソース取得・他者への再現方法の提供」という4要素がNixの仕組みによってすでに解決されていたと報告した。同ツールはソースパネル、スタックフレーム、スレッドレーン、Compare機能などを追加し急成長している。
Zakaria氏が開発する「Rewind VM」は、Nixビルドの全実行をその入力とスレッドスケジュールの純粋関数として再現する決定論的VMだ。氏はこれを使い、多数のレースコンディションの発見・再現・修正を行ってきた。
典型例として示されたのは、2スレッドが1つの銀行口座に同時入金するシナリオ。各スレッドが「残高読み取り→台帳書込み→残高保存」を行う間に他方が割り込むと、古い残高が上書きされ資金が消える。氏の16コアノートPCでは1,000回中396回で資金損失が発生した一方、`taskset`でシングルコアに固定すると損失ゼロになった。これがRewindがスケジュールを意図的に乱す理由だ。
`rewind check`コマンドは異なるスケジュールでビルドを複数回実行し、障害の原因となる最初のステップを一点に絞り込む。実行例では「ステップ3237でのリスケジュールが障害を引き起こす」と特定するまで11秒で完了した。
ここでNixが果たした役割が大きい。デバッガーには通常、プログラムの正確な入力・デバッグシンボル・ソースコード・依存ライブラリのソース・他者が同環境を再現する手段という5要素が必要だ。これはNixのderivationそのものが持つ情報と完全に一致する。`rewind nix`はderivationの入力クロージャをread-only erfsイメージに梱包してVMを起動し、実行IDは入力のハッシュとして管理される。ビルド成功時にはNARハッシュをバイナリキャッシュと照合し整合性を確認する。
氏は「新機能を追加するたびに大規模な実装が必要かと思ったが、常に同じことに気づいた——困難な部分はすでにNixが解決していた」と述べている。