See attached
Created attachment 469114 [details] gdb backtrace
Created attachment 469116 [details] emerge --info
Version numbers: dev-vcs/tig-2.2.1::gentoo was built with the following: USE="unicode" ABI_X86="64" sys-libs/ncurses-5.9-r101::gentoo was built with the following: USE="tinfo unicode -gpm" ABI_X86="32 64 -x32" sys-libs/ncurses-6.0-r1::gentoo was built with the following: USE="cxx threads tinfo unicode -ada -debug -doc -gpm -minimal -profile -static-libs -test -trace" ABI_X86="32 64 -x32"
tig version 2.1.1 works fine.
tig version 2.2 works fine as well. For now I'd suggest readding version 2.2 back to the portage tree until the segfault in 2.2.1.
It would be nice to have more info here than a simple backtrace. 1. How are you triggering the segfault? For example, is it from simply opening tig against a repo or some certain key combo within tig on a repo? 2. Is it always reproducible under the same conditions against any repo? 3. Does the live ebuild also segfault in the same manner?
Just typing "tig" by itself triggers the segfault, even against a live copy of the main dev tree for gentoo itself. It appears to trigger against all repos. I only noticed when 2.2.1 was stabilized.
And yes, the live ebuild segfaults in the same manner as of yesterday.
I assume it's this bug, https://github.com/jonas/tig/issues/568.
https://github.com/jonas/tig/pull/585 The 9999 version works as of now.
2.2.1-r1 now includes the relevant patch.