watcher watches $HOME for some inputs (which leads to crashes)

[blaxill]

The example project works for me, but unfortunately when trying one of my existing projects I get a panic for both master and rolling-release lorri branches:

name = 'lorri'
operating_system = 'unix:OSX'
crate_version = '0.1.0'
explanation = '''
Panic occurred in file 'src/build_loop.rs' at line 78
'''
cause = 'Error cause could not be determined by the application.'
method = 'Panic'
backtrace = '''

   0: 0x10e2b5fe7 - lorri::build_loop::BuildLoop::forever::h95d7a050d3988e7a
   1: 0x10e2b96f1 - std::sys_common::backtrace::__rust_begin_short_backtrace::hbeaadf6cf3a4bdbf
   2: 0x10e279e95 - std::panicking::try::do_call::hd4d17cb3d7fbc859
   3: 0x10e3ee63f - __rust_maybe_catch_panic
   4: 0x10e27b3a5 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hb0cf92fd49c54999
   5: 0x10e3d637e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::hab5268a06f594cc7
   6: 0x10e3da04e - std::sys::unix::thread::Thread::new::thread_start::h7efbb7639d00609d
   7: 0x7fff6ad3a305 - _pthread_body
   8: 0x7fff6ad3d26f - _pthread_start'''

My shell.nix works outside of lorri, and is basically a normal haskellPackages.developPackage, with Niv for dependency pinning:

let sources = import ./nix/sources.nix;
    pkgs = import ./nix { inherit sources; };
    haskellPackages = pkgs.haskell.packages.ghc865;

in haskellPackages.developPackage {
  root = (pkgs.gitignore.gitignoreSource ./.);

  ...overrides & modifiers...
}

The panic occurs with both lorri daemon and lorri watch:

> lorri daemon
lorri: ready
Started(
    ProjectAdded(
        NixFile(
            "[deleted]/shell.nix",
        ),
    ),
)
Well, this is embarrassing.

lorri 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 "/var/folders/yw/chnvtb_55352_ff6w8wjycnm0000gn/T/report-96600ef7-ac12-48e8-bcfa-2dade0a05ae8.toml". Submit an issue or email with the subject of "lorri Crash Report" and include the report as an attachment.

- Homepage: https://github.com/target/lorri
- Authors: Graham Christensen <graham.christensen@target.com>

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!

[Profpatsch]

I’m sorry, human panic threw away the important bit …

Could you re-run with RUST_BACKTRACE=1 set in the environment?

[blaxill]

Ah yeah this looks a little more helpful:

thread '<unnamed>' panicked at 'Unrecoverable error:
Notify(
    Io(
        Os {
            code: 13,
            kind: PermissionDenied,
            message: "Permission denied",
        },
    ),
)', src/build_loop.rs:78:21
stack backtrace:
   0:        0x10dc222f4 - std::sys_common::backtrace::print::hcd90b79be548354a
   1:        0x10dc0ed69 - std::panicking::default_hook::{{closure}}::hd679ef6390e41f36
   2:        0x10dc0eb02 - std::panicking::default_hook::hea22b91123a9976a
   3:        0x10dc0f4a0 - std::panicking::rust_panic_with_hook::h8f3f13e5d674379c
   4:        0x10dc0effd - std::panicking::continue_panic_fmt::h4fe3af2f9b448ae0
   5:        0x10dc0ef51 - std::panicking::begin_panic_fmt::h68a3671668cc3bee
   6:        0x10daebfe7 - lorri::build_loop::BuildLoop::forever::h95d7a050d3988e7a
   7:        0x10daef6f1 - std::sys_common::backtrace::__rust_begin_short_backtrace::hbeaadf6cf3a4bdbf
   8:        0x10daafe95 - std::panicking::try::do_call::hd4d17cb3d7fbc859
   9:        0x10dc2463f - __rust_maybe_catch_panic
  10:        0x10dab13a5 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hb0cf92fd49c54999
  11:        0x10dc0c37e - <alloc::boxed::Box<F> as core::ops::function::FnOnce<A>>::call_once::hab5268a06f594cc7
  12:        0x10dc1004e - std::sys::unix::thread::Thread::new::thread_start::h7efbb7639d00609d
  13:     0x7fff6ad3a305 - _pthread_body
  14:     0x7fff6ad3d26f - _pthread_start

I'm not sure why there is a permission error, is there any traces you'd like me to run?

sudo dtruss -t open -p 3466
dtrace: system integrity protection is on, some features will not be available

SYSCALL(args) 		 = return
open("/dev/urandom\0", 0x1000000, 0x1B6)		 = 5 0
open("/Users/ben/Library/Caches/com.github.target.lorri.lorri.lorri/cas/4a06de72ed6a4fe178f4a02ad1d642be\0", 0x1000A01, 0x1B6)		 = -1 Err#17
open("/dev/null\0", 0x1000000, 0x1B6)		 = 5 0
open("/dev/urandom\0", 0x1000000, 0x1B6)		 = 5 0

[Profpatsch]

What’s the output if you run with lorri -vvv?

You could try what happens if you play around with https://github.com/emcrisostomo/fswatch, whether you also get permission denied errors.

[blaxill]

Ah- It looks like hercules-ci/gitignore is causing lorri to generalize paths incorrectly:

[2019-11-14T02:52:18Z INFO  lorri::daemon] pinged with /Users/ben/code/picodma-fpga/shell.nix
Started(
    ProjectAdded(
        NixFile(
            "/Users/ben/code/picodma-fpga/shell.nix",
        ),
    ),
)
[2019-11-14T02:52:18Z DEBUG lorri::builder] $ "nix-instantiate" "-vv" "--add-root" "/var/folders/yw/chnvtb_55352_ff6w8wjycnm0000gn/T/.tmpT2zS2k/result" "--indirect" "--argstr" "runTimeClosure" "/nix/store/qkl94nk66bj30pydzs6y6bcvah401772-runtime-closure.nix" "--argstr" "src" "/Users/ben/code/picodma-fpga/shell.nix" "--" "/Users/ben/Library/Caches/com.github.target.lorri.lorri.lorri/cas/4a06de72ed6a4fe178f4a02ad1d642be"
[2019-11-14T02:52:31Z DEBUG lorri::nix] "nix-build" "--out-link" "/var/folders/yw/chnvtb_55352_ff6w8wjycnm0000gn/T/.tmpfumLu4/result" "--" "/var/folders/yw/chnvtb_55352_ff6w8wjycnm0000gn/T/.tmpT2zS2k/result"
[2019-11-14T02:52:31Z DEBUG lorri::build_loop] original paths: 3017
[2019-11-14T02:52:31Z DEBUG lorri::build_loop]   -> reduced to: 1
[2019-11-14T02:52:31Z DEBUG lorri::watch] Watching path "/Users/ben"
[2019-11-14T02:52:31Z DEBUG lorri::watch] Watching parent path "/Users"
[2019-11-14T02:52:31Z DEBUG lorri::watch] Watching path "/Users/ben/.config"
[2019-11-14T02:52:31Z DEBUG lorri::watch] Watching path "/Users/ben/.config/nix"
[2019-11-14T02:52:31Z DEBUG lorri::watch] Watching path "/Users/ben/.config/configstore"
..all my .config until it hits a permission error..

Changing

in haskellPackages.developPackage {
  root = (pkgs.gitignore.gitignoreSource ./.);

to

in haskellPackages.developPackage {
  root = ./.;

is a workaround.

[Profpatsch]

This also happened in #103 (comment), although on Linux. There is a bug in the watcher somewhere.

[curiousleo]

Ah- It looks like hercules-ci/gitignore is causing lorri to generalize paths incorrectly

Looking into this @blaxill, thanks for explaining that you're using hercules-ci/gitignore! My hunch right now is that

• Reads parent gitignores even if only pointed at a subdirectory

(https://github.com/hercules-ci/gitignore#features) could be the issue.

My hypothesis right now is that if this gitignore depends in the Nix sense on all its ancestor directories, then lorri will pick up all those paths as dependencies and start watching them. And because lorri watches directories recursively, it will end up watching all the paths, overloading the file watch API.

[Profpatsch]

My hypothesis right now is that if this gitignore depends in the Nix sense on all its ancestor directories,

Ah, you are absolutely right I think! I always thought that was a bad idea (mostly because of hermeticity), but now I have proof. :P

I wonder how lorri could deal with this. We might be able to create a lint check for something like that.

[roberth]

@Profpatsch, before removing the gitignore lib everywhere, remember that hermeticity is lost when any of your user-configured tools writes to the worktree, and gitignore fixes that.

[Profpatsch]

remember that hermeticity is lost when any of your user-configured tools writes to the worktree, and gitignore fixes that.

That’s true. But taking into account out-of-repository .gitignore files kills hermeticity between developers (or developer and CI/build server).

[roberth]

Also true. Can't have both.

[Profpatsch]

I’m gonna close this, since we can’t really do anything about nix code that lists parent directories.