empty `flake.lock` triggers `std::terminate` due to unhandled json parsing exception #661

New issue

Closed

opened 2025-02-07 22:02:12 +00:00 by ink-splatters · 4 comments

ink-splatters commented

2025-02-07 22:02:12 +00:00

Describe the bug

subj

Steps To Reproduce

given valid flake.nix exists in the current directory:

❯ truncate -s 0 flake.lock
❯ nix flake lock

BANG!

warning: Git tree '/tmp/lix-issue' is dirty
Lix crashed. This is a bug. We would appreciate if you report it along with what caused it at https://git.lix.systems/lix-project/lix/issues with the following information included:

Exception: nlohmann::json_abi_v3_11_3::detail::parse_error: [json.exception.parse_error.101] parse error at line 1, column 1: attempting to parse an empty input; check that your input string or stream contains the expected JSON
Stack trace:
 0# nix::printStackTrace() in /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/lib/liblixutil.dylib
 1# nix::(anonymous namespace)::onTerminate() in /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/lib/liblixmain.dylib
 2# std::__terminate(void (*)()) in /nix/store/md8l82d1ggi4136ja9qdpg855z6wavip-libcxx-16.0.6/lib/libc++abi.1.0.dylib
 3# std::terminate() in /nix/store/md8l82d1ggi4136ja9qdpg855z6wavip-libcxx-16.0.6/lib/libc++abi.1.0.dylib
 4# nix::handleExceptions(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::function<void ()>) in /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/lib/liblixmain.dylib
 5# main in /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/bin/nix

Abort trap: 6

Expected behavior

lix should not crash when attempting to parse invalid json file (flake.lock)

`nix --version` output

nix (Lix, like Nix) 2.92.0
System type: aarch64-darwin
Additional system types: x86_64-darwin
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /Users/ic/.config/nix/nix.conf:/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/share

## Describe the bug subj ## Steps To Reproduce given valid `flake.nix` exists in the current directory: ```shell ❯ truncate -s 0 flake.lock ❯ nix flake lock ``` <details> <summary> BANG! </summary> ```shell warning: Git tree '/tmp/lix-issue' is dirty Lix crashed. This is a bug. We would appreciate if you report it along with what caused it at https://git.lix.systems/lix-project/lix/issues with the following information included: Exception: nlohmann::json_abi_v3_11_3::detail::parse_error: [json.exception.parse_error.101] parse error at line 1, column 1: attempting to parse an empty input; check that your input string or stream contains the expected JSON Stack trace: 0# nix::printStackTrace() in /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/lib/liblixutil.dylib 1# nix::(anonymous namespace)::onTerminate() in /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/lib/liblixmain.dylib 2# std::__terminate(void (*)()) in /nix/store/md8l82d1ggi4136ja9qdpg855z6wavip-libcxx-16.0.6/lib/libc++abi.1.0.dylib 3# std::terminate() in /nix/store/md8l82d1ggi4136ja9qdpg855z6wavip-libcxx-16.0.6/lib/libc++abi.1.0.dylib 4# nix::handleExceptions(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>> const&, std::__1::function<void ()>) in /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/lib/liblixmain.dylib 5# main in /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/bin/nix Abort trap: 6 ``` </details> ## Expected behavior `lix` should not crash when attempting to parse invalid json file (`flake.lock`) ## `nix --version` output ``` nix (Lix, like Nix) 2.92.0 System type: aarch64-darwin Additional system types: x86_64-darwin Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /Users/ic/.config/nix/nix.conf:/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/y9mgqlvgyh0ixd0vgyn1y4kjgsn2gw36-lix-2.92.0/share ```

ink-splatters added the

bug

label

2025-02-07 22:02:12 +00:00

jade added the

Area/flakes

E/reproducible

crash 💥

labels

2025-02-07 23:07:10 +00:00

jade commented

2025-02-08 03:13:07 +00:00

Owner

maybe same underlying bug? #642 but unclear if this is a duplicate

maybe same underlying bug? https://git.lix.systems/lix-project/lix/issues/642 but unclear if this is a duplicate

gilice commented

2025-02-20 16:46:05 +00:00

Member

Cannot reproduce.
I suspect this has been fixed in the commit fixing #559:

$ cd $(mktemp -d)
$ nix flake init
$ truncate -s 0 flake.lock
$ nix flake lock
fetching path input 'path:/tmp/tmp.GUm2vzAnCz'
error:
       … while updating the lock file of flake 'path:/tmp/tmp.GUm2vzAnCz?lastModified=1740069829&narHash=sha256-PYp4NX9iU9iZai0Pm0SVzicgvGhxvYwbfUdp7wowYPE%3D'

       … while parsing the lock file at /nix/store/z7kpfana7gcmvgsbdhr6dxklidw4rn3f-source//flake.lock

       error: [json.exception.parse_error.101] parse error at line 1, column 1: attempting to parse an empty input; check that your input string or stream contains the expected JSON

Of course, it is debatable if we should just re-generate the flake.lock if it is empty. Opinions on that?

Cannot reproduce. I suspect this has been fixed in the commit fixing #559: ```term $ cd $(mktemp -d) $ nix flake init $ truncate -s 0 flake.lock $ nix flake lock fetching path input 'path:/tmp/tmp.GUm2vzAnCz' error: … while updating the lock file of flake 'path:/tmp/tmp.GUm2vzAnCz?lastModified=1740069829&narHash=sha256-PYp4NX9iU9iZai0Pm0SVzicgvGhxvYwbfUdp7wowYPE%3D' … while parsing the lock file at /nix/store/z7kpfana7gcmvgsbdhr6dxklidw4rn3f-source//flake.lock error: [json.exception.parse_error.101] parse error at line 1, column 1: attempting to parse an empty input; check that your input string or stream contains the expected JSON ``` Of course, it is debatable if we should just re-generate the `flake.lock` if it is empty. Opinions on that?

pennae commented

2025-02-20 16:52:28 +00:00

Owner

regenerating it seems rather dangerous, considering that "file suddenly empty" is a known crash recovery mode of some file systems. we should at least ask whether that's something the user wants to do as they may have just made a mistake and want to roll back the lockfile to a vcs version instead