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!