random() is not thread-safe, it relies on global state, and calling it from worker threads can result in multiple threads producing the same value. It also doesn't guarantee unique values even in single-threaded use. Use an atomic counter for the use-case of generating temporary paths, and switch to a thread-local RNG for the one remaining call. This will probably fix https://github.com/NixOS/nix/issues/7273 though I'm not willing to risk corrupting my store to find out. Change-Id: I4c4c4c9796613573ffefd29cc8efe3d07839facc
543 B
543 B
synopsis, issues, cls, category, credits
| synopsis | issues | cls | category | credits | ||
|---|---|---|---|---|---|---|
| Fix potential store corruption with auto-optimise-store |
|
|
Fixes | lilyball |
Optimising store paths (and other operations involving temporary files) no longer use random(3)
to generate filenames. On darwin systems this was observed to potentially cause store corruption
when using auto-optimise-store,
though this corruption was possible on any system whose random(3) does not have locking around
the global state.