pijul record crashed with:

Well, this is embarrassing.

pijul had a problem and crashed. To help us diagnose the problem you can send us a crash report.

We have generated a report file at "/run/user/1000/report-afe5fc1a-4f6d-41af-a65d-7efc169e5247.toml". Submit an issue or email with the subject of "pijul Crash Report" and include the report as an attachment.

- Authors: Pierre-Étienne Meunier <pe@pijul.org>

We take privacy seriously, and do not perform any automated error collection. In order to improve the software, we rely on people to submit reports.

Thank you kindly!

name = 'pijul'
operating_system = 'unix:Unknown'
crate_version = '1.0.0-beta'
explanation = '''
Panic occurred in file '/build/pijul-1.0.0-beta-vendor.tar.gz/libpijul/src/change/text_changes.rs' at line 790
'''
cause = 'assertion failed: !contents.is_empty()'
method = 'Panic'
backtrace = '''

   0: 0x5650ac4f5f5d - core::panicking::panic::hf2a1a8726f570f0d
   1: 0x5650acaec15b - libpijul::change::text_changes::<impl libpijul::change::BaseHunk<libpijul::change::Atom<core::option::Option<libpijul::pristine::hash::Hash>>,libpijul::change::Local>>::from_printable::h0a53a660abcecaca
   2: 0x5650acae4f89 - libpijul::change::text_changes::<impl libpijul::change::LocalChange<libpijul::change::BaseHunk<libpijul::change::Atom<core::option::Option<libpijul::pristine::hash::Hash>>,libpijul::change::Local>,libpijul::change::Author>>::update::hdc01a05fa0797118
   3: 0x5650ac7c476c - libpijul::change::text_changes::<impl libpijul::change::LocalChange<libpijul::change::BaseHunk<libpijul::change::Atom<core::option::Option<libpijul::pristine::hash::Hash>>,libpijul::change::Local>,libpijul::change::Author>>::read_and_deps::h5bd4438e0d9d3602
   4: 0x5650ac6b3df6 - pijul::commands::record::Record::run::h4a0c3346fe85d4c6
   5: 0x5650ac6824fa - pijul::run::{{closure}}::h992aaad23b0a5a87
   6: 0x5650ac63e4dd - <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll::h133a2e271d8e0fe4
   7: 0x5650ac590f48 - tokio::park::thread::CachedParkThread::block_on::h8129d534ab6082a6
   8: 0x5650ac59114d - tokio::runtime::thread_pool::ThreadPool::block_on::h99674d727e5f29e6
   9: 0x5650ac6a0b70 - tokio::runtime::Runtime::block_on::hc40fb0f950f5342b
  10: 0x5650ac6fd73e - pijul::main::h601977234f383d38
  11: 0x5650ac57f363 - std::sys_common::backtrace::__rust_begin_short_backtrace::h717595a5e0cf2a63
  12: 0x5650ac5f3249 - std::rt::lang_start::{{closure}}::hd6f1ecf4d72d8dfd
  13: 0x5650acdd0ff1 - std::rt::lang_start_internal::hc2cb966a7a4d713d
  14: 0x5650ac6fd882 - main
  15: 0x7f4132bed780 - __libc_start_main
  16: 0x5650ac4f633a - _start
  17:        0x0 - <unresolved>'''

I believe this is related to editors trimming whitespace:

# Hunks

6. Edit in ".ignore":19 2.32 "UTF-8"
  up 2.165, new 286:316, down
+ 
+ # Generated

records fine while

# Hunks

6. Edit in ".ignore":19 2.32 "UTF-8"
  up 2.165, new 286:316, down
+
+ # Generated

crashes (note the difference between + and +).

This I assume is theoretically fixed by T4VEIGHRHLIEFURXDJH76NITPFXQLFP4SJUXOIKDPDQMWLIG2IKAC, but that hasn’t hit nix unstable yet, so I haven’t been able to confirm this is a non-issue for the next release. If someone with a version that includes that change can test and confirm its fixed, I will close this. :-)

Not that related but… in case of a syntax error (in that file at the very least), it keeps re-opening the editor until you Ctrl-C pijul. It is quite annoying. Is it possible to continue from where you left off[1] if you Ctrl-C? If so, then there should not be any need to keep re-opening the editor upon syntax error. If there is no way to continue from where you left off, then consider this a FEATURE REQUEST.

You may want to heavily read into file locking (flock, fcntl, etc.), journaling, and write-ahead logging. A version control system must be as resistant as possible to power outages and so forth. Ultimately you are still relying on the kernel and the hardware, but you have to do everything in your power to ensure atomicity or the ability to detect failure and the ability to continue or rollback. git implements it, you may want to take a look at its source code.

Is recording atomic? I did realize that you are using temporary files which is a good start. Make sure to check for hard link counts as well, it is an old trick.

[1] Similar to git {merge,rebase} --abort or git {merge,rebase} --continue.