gitui: Crash on 0.22.1: Error: receiving on an empty and disconnected channel

Describe the bug Whenever I open gitui on my main repo, it starts, and crashes after a few seconds, with this output in the console:

Error: receiving on an empty and disconnected channel

On other git repos, it does open with no issue .

To Reproduce Steps to reproduce the behavior:

  1. Simply open gitui on my main repo Don’t know what specifically makes it happen only on my main repo 😕

Expected behavior Gitui opens, life is good.

Context (please complete the following information):

  • Ubuntu 22.04.1LTS
  • GitUI Version 0.22.1
  • Rust version: Tried with 1.63.0 and 1.65.0

Additional context This crash happens on gitui 0.22.1. With 0.21.0, everything is fine.

With gitui 0.22.0, gitui crashes without even opening, with this message:

Error: Permission denied (os error 13) about ["XXX"]

where XXX is a git-ignored folder owned by root inside my git folder (docker volume) No idea if this is linked or not.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 6
  • Comments: 24 (4 by maintainers)

Commits related to this issue

Most upvoted comments

this should be fixed in the next release via #1444

Ah, okay, here’s the repro of what was actually wrong in my repo: having a symlink to a folder which somewhere within contains a directory that the current user cannot read leads to this crash. This happens even if the symlink in question is gitignored.

# Setup
mkdir other-folder
sudo install -d -o root -m 500 other-folder/root-dir

# Repro
mkdir git-folder
cd git-folder
git init
ln -s ../other-folder
gitui

And here’s the log:

20:44:05 [TRACE] (6) mio::poll: [/build/gitui-0.22.1-vendor.tar.gz/mio/src/poll.rs:532] registering event source with poller: token=Token(0), interests=READABLE
20:44:05 [TRACE] (1) gitui::watcher: [src/watcher.rs:21] poll watcher: false recommended: Inotify
20:44:05 [TRACE] (6) mio::poll: [/build/gitui-0.22.1-vendor.tar.gz/mio/src/poll.rs:532] registering event source with poller: token=Token(1), interests=READABLE
20:44:05 [TRACE] (1) gitui::app: [src/app.rs:119] open repo at: RefCell { value: Path(".") }
20:44:05 [TRACE] (7) mio::poll: [/build/gitui-0.22.1-vendor.tar.gz/mio/src/poll.rs:532] registering event source with poller: token=Token(0), interests=READABLE
20:44:05 [TRACE] (1) asyncgit::status: [asyncgit/src/status.rs:102] request: [hash: 1914527838217914819] (type: WorkingDir)
20:44:05 [TRACE] (1) asyncgit::status: [asyncgit/src/status.rs:102] request: [hash: 11738432472621175661] (type: Stage)
20:44:05 [TRACE] (1) gitui: [src/main.rs:200] app start: 15 ms
20:44:05 [TRACE] (1) gitui::app: [src/app.rs:477] update
20:44:05 [TRACE] (4) asyncgit::status: [asyncgit/src/status.rs:160] status fetched: 11738432472621175661 (type: Stage)
20:44:05 [TRACE] (3) asyncgit::status: [asyncgit/src/status.rs:160] status fetched: 1914527838217914819 (type: WorkingDir)
20:44:05 [TRACE] (1) asyncgit::status: [asyncgit/src/status.rs:102] request: [hash: 11994321254544498947] (type: WorkingDir)
20:44:05 [TRACE] (1) asyncgit::status: [asyncgit/src/status.rs:102] request: [hash: 9554824137031149479] (type: Stage)
20:44:05 [TRACE] (4) asyncgit::status: [asyncgit/src/status.rs:160] status fetched: 9554824137031149479 (type: Stage)
20:44:05 [TRACE] (2) asyncgit::status: [asyncgit/src/status.rs:160] status fetched: 11994321254544498947 (type: WorkingDir)
20:44:05 [ERROR] panic: PanicInfo { payload: Any { .. }, message: Some(Watch error: Error { kind: Io(Os { code: 13, kind: PermissionDenied, message: "Permission denied" }), paths: ["/home/user/tmp/gitui-test2/git-folder/other-folder/root-dir"] }), location: Location { file: "src/watcher.rs", line: 105, col: 14 }, can_unwind: true }
trace:
   0: gitui::set_panic_handlers::{{closure}}
   1: std::panicking::rust_panic_with_hook
   2: std::panicking::begin_panic_handler::{{closure}}
   3: std::sys_common::backtrace::__rust_end_short_backtrace
   4: rust_begin_unwind
   5: core::panicking::panic_fmt
   6: core::result::unwrap_failed
   7: core::result::Result<T,E>::expect
   8: std::sys_common::backtrace::__rust_begin_short_backtrace
   9: core::ops::function::FnOnce::call_once{{vtable.shim}}
  10: std::sys::unix::thread::Thread::new::thread_start
  11: start_thread
  12: __clone3

20:44:05 [TRACE] (1) gitui::app: [src/app.rs:496] update_async: Git(Branches)
20:44:05 [TRACE] (1) gitui::app: [src/app.rs:496] update_async: Git(Status)
20:44:05 [TRACE] (1) asyncgit::diff: [asyncgit/src/diff.rs:98] request DiffParams { path: ".gitignore", diff_type: WorkDir, options: DiffOptions { ignore_whitespace: false, context: 3, interhunk_lines: 0 } }
20:44:05 [TRACE] (1) gitui::app: [src/app.rs:496] update_async: Git(Status)
20:44:05 [TRACE] (1) asyncgit::diff: [asyncgit/src/diff.rs:98] request DiffParams { path: ".gitignore", diff_type: WorkDir, options: DiffOptions { ignore_whitespace: false, context: 3, interhunk_lines: 0 } }
20:44:05 [TRACE] (1) gitui::app: [src/app.rs:496] update_async: Git(Status)
20:44:05 [TRACE] (1) gitui::app: [src/app.rs:496] update_async: Git(Status)
20:44:05 [TRACE] (1) gitui::app: [src/app.rs:496] update_async: Git(Diff)
20:44:05 [ERROR] notify receive error: receiving on a closed channel

In my real-world case, my project folder has a gitignored folder which is mounted as the /home partition in a VM. That gitignored folder then ends up containing symlinks to the /home/$USER/.local folder on the host, which happens to contains some installed Steam games, which apparently includes some files and folders owned by root when using Proton to install Windows games.

imo, there are two bugs with the current behavior:

  • since symlinks are stored as such in git, symlinks should probably not be followed when adding file watches
  • gitignored files and directories also probably also shouldn’t be watched

And then I guess it’s also debatable whether or not failing to set a watch when not in --polling mode should be a critical error or not. At the very least, a better error message would be nice.

Hi @extrawurst ,

I also observe the same buggy behaviour with 0.22.1 :

$ gitui --directory=<my_gitdir> --workdir=<my_workdir> => crashes with ‘Error: receiving on an empty and disconnected channel

$ gitui --directory=<my_gitdir> --workdir=<my_workdir> --polling => no crashes

NOTE: 0.21.0 does not have the same problem

I have hacked together a fix for this. You can try it out on https://github.com/michaeladler/gitui (master branch, rebased occassionally to keep it up to date with this repo). I have been using it for two weeks and it works like a charm for me. I’ve been meaning to submit a merge request here, but I’ll be waiting for a few days more hoping to gain some feedback from other users who are affected by it.

Regarding the use of --polling, in my case it does indeed bypass the issue, but at a cost: the background polling is creating an undue load on the cpu. Its ok for now, but a real fix would be better 😃

I am also seeing this. No logs with gitui -l, however with --polling it does not crash.

I observe the same crash. I am not using --directory or --workdir.

A plain gitui crashes, while a gitui --polling does not crash.

Details of software versions etc. in #1467.

also since gitui now remembers the previously opened Tab, it is very hard to switch to a non-crashing Tab again.

you can manipulate the tab opened on startup in .git/gitui