kejadlen/git-together

segmentation fault after upgrading to macOS Catalina

LukeWinikates opened this issue · 5 comments

We're reproduced this on a couple of iMacs - git-together was previously installed (under macOS Mojave), then started showing segfaults after the upgrade to Catalina. It does appear that the git-together commands work, since the terminal integration showing the active pair does show it changing, even after the segfault message. Not sure if the warning about the panic from calling git-together with no arguments is normal, or connected to the same segfault issue.

± lw |master {7} ✓| → git with lw ns
Segmentation fault: 11

± lw+ns |master {7} ✓| → git-together
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/50f8aadd746ebc929a752e5ffb133936ee75c52f/src/libcore/macros.rs:41:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

± lw+ns |master {7} ✓| → git --version
git version 2.24.1

Run git config --file .git-together --add git-together.domain YOUR.DOMAIN and try again. Worked for us when we upgraded engineer workstations to Catalina, though running just git still triggers the error, it seems to have went away otherwise.

Can you run with RUST_BACKTRACE=1 to see the stacktrace? I don't have a handy Catalina install to use to look at this right now.

I am able to run git with successfully, but get the same error running git-together:

$ RUST_BACKTRACE=1 git-together
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/50f8aadd746ebc929a752e5ffb133936ee75c52f/src/libcore/macros.rs:41:40
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::panicking::panic
   9: git_together::run
  10: git_together::main
  11: std::rt::lang_start::{{closure}}
  12: main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I tried @marcjmiller's suggestion, and didn't seem to see any effect. RUST_BACKTRACE=1 git with lw didn't produce any output beyond Segmentation fault: 11.

Here's the RUST_BACKTRACE=full git-together output:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /rustc/50f8aadd746ebc929a752e5ffb133936ee75c52f/src/libcore/macros.rs:41:40
stack backtrace:
   0:        0x106a6eea2 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hf286698d267e2898
   1:        0x106a4bb40 - core::fmt::write::h9290bfa3178df660
   2:        0x106a6e48b - std::io::Write::write_fmt::h6bd7ef48ec38cefc
   3:        0x106a6e073 - std::panicking::default_hook::{{closure}}::hdca182c87a927aee
   4:        0x106a6d5c1 - std::panicking::rust_panic_with_hook::h3098f3bc5bfa8393
   5:        0x106a7234d - std::panicking::continue_panic_fmt::h0476f02b3ab9bb6e
   6:        0x106a7dbd9 - rust_begin_unwind
   7:        0x106a4a2cc - core::panicking::panic_fmt::h3809e243f5d33a59
   8:        0x106a4a764 - core::panicking::panic::hae83cd2978d748b8
   9:        0x106a5686a - git_together::run::ha434c872c3372404
  10:        0x106a4343e - git_together::main::h83987351607731d5
  11:        0x106a61526 - std::rt::lang_start::{{closure}}::h8089f6447f9d7ea2
  12:        0x106a43cf4 - main

That's all I've got for now, doesn't seem like any new information. I suspect rebuilding from source on a Catalina machine might be interesting to try.

Looks like it was caused by #43, so unrelated to Catalina:

https://github.com/kejadlen/git-together/blob/master/src/lib.rs#L58

Should be a straightforward fix, PRs welcome!