Garbage collection of "too many" paths is unsound #524

Open
opened 2024-09-14 18:21:06 +00:00 by raito · 4 comments
Owner

Describe the bug

TL;DR: Garbage collection of large Nix stores can leave the Nix store in an inconsistent state, e.g. referrers without ValidPath rows.

Motivated by https://gerrit.lix.systems/c/lix/+/1916. I have found a curious case of corruption, inconsistencies, idk?

Steps To Reproduce

Way 1: Consult the test in the CL, emit a DELETE to a referenced valid path that bypasses the foreign key constraints (can be done by PRAGMA foreign_keys = OFF; in the session)
Way 2: To discover yet.

Expected behavior

(1) GC should always succeed.
(2) GC/deletion/etc. should never leave the DB in the wrong state.

nix --version output

Happened to me for every version of Nix ≥ 2.18, including Lix ≥ 2.90.

Additional context

The diagnostic may be wrong.

## Describe the bug TL;DR: Garbage collection of large Nix stores can leave the Nix store in an inconsistent state, e.g. referrers without ValidPath rows. Motivated by https://gerrit.lix.systems/c/lix/+/1916. I have found a curious case of corruption, inconsistencies, idk? ## Steps To Reproduce Way 1: Consult the test in the CL, emit a `DELETE` to a **referenced valid path** that bypasses the foreign key constraints (can be done by `PRAGMA foreign_keys = OFF;` in the session) Way 2: To discover yet. ## Expected behavior (1) GC should always succeed. (2) GC/deletion/etc. should never leave the DB in the wrong state. ## `nix --version` output Happened to me for every version of Nix ≥ 2.18, including Lix ≥ 2.90. ## Additional context The diagnostic may be wrong.
raito added the
bug
label 2024-09-14 18:21:06 +00:00
jade added the
Area/store
label 2024-09-14 19:17:57 +00:00
Owner

#505

maybe also part of the observed behaviour

https://git.lix.systems/lix-project/lix/issues/505 maybe also part of the observed behaviour
Author
Owner

Actually, my root cause analysis seems wrong, FWIW, I expanded why in the Gerrit CL commit message, I will update the initial description.

Actually, my root cause analysis seems wrong, FWIW, I expanded why in the Gerrit CL commit message, I will update the initial description.
raito changed title from Garbage collection of long-chained derivations is unsound to Garbage collection of "too many" paths is unsound 2024-09-14 21:20:23 +00:00
Owner

I believe that option 1 ought to be impossible, since some trivial auditing reveals that we only call sqlite3_* functions (besides setting some pragmas or pure reads) inside of sqlite.cc inside of some kind of wrapper class that should have set the appropriate foreign keys pragma.

This leads me to wonder: races, somehow? It shouldn't be so, though.

I believe that option 1 ought to be impossible, since some trivial auditing reveals that we only call sqlite3_* functions (besides setting some pragmas or pure reads) inside of sqlite.cc inside of some kind of wrapper class that should have set the appropriate foreign keys pragma. This leads me to wonder: races, somehow? It shouldn't be so, though.
Author
Owner

@jade Yeah, this is what I wrote in the commit message of the CL as well. SQLite is transactional, though, so races are all serialized in front of the consistency in principle. You cannot add back a (referrer, reference) pair if the referrer does not exist. You cannot delete a valid path's referrer if there's still (referrer, reference) pairs in Refs table, etc.

@jade Yeah, this is what I wrote in the commit message of the CL as well. SQLite is transactional, though, so races are all serialized in front of the consistency in principle. You cannot add back a (referrer, reference) pair if the referrer does not exist. You cannot delete a valid path's referrer if there's still (referrer, reference) pairs in Refs table, etc.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: lix-project/lix#524
No description provided.