git-absorb died of signal 11

[sluongng]

I tried using git-absorb today and just got an error message

> git absorb -b 1a44517693e2c1c030f278966797a1ee0ac3cf5b -v -r
error: git-absorb died of signal 11
exit 139

> git absorb -V
git-absorb 0.6.7

No clue how to troubleshoot this 🤔

[tummychow]

signal 11 is a segfault, which probably means a libgit2 issue. i'll have to check what libgit2 is getting statically linked as part of the crate. do you have a repo that reproduces the issue? (including the index state at the time that you run git-absorb)

[sluongng]

No sorry it was in an internal repository cannot be shared

I tried to diff the git config between a small repo of mine where git-absorb was working

--- /tmp/1.txt  2022-06-07 09:08:55.932322950 +0200
+++ /tmp/2.txt  2022-06-07 09:12:07.788995354 +0200
@@ -2,43 +2,29 @@
 alias.co=checkout
 alias.st=status
 branch.master.merge=refs/heads/master
 color.ui=true
-commit.template=/Users/sngoc/.gitmessage
 commit.verbose=true
 core.bare=false
 core.editor=nvim
 core.filemode=true
-core.fsmonitor=.git/hooks/fsmonitor-watchman-v2
-core.fsmonitorhookversion=2
 core.ignorecase=true
 core.logallrefupdates=true
 core.pager=less -X -F
 core.precomposeunicode=true
 core.repositoryformatversion=0
-core.sparsecheckout=false
-core.sparsecheckoutcone=false
 credential.credentialstore=keychain
 credential.gitlabauthmodes=browser
 credential.guiprompt=false
 credential.helper=/usr/local/share/gcm-core/git-credential-manager-core
 diff.wserrorhighlight=all
 extensions.worktreeconfig=true
-feature.experimental=1
-feature.manyfiles=1
 filter.lfs.clean=git-lfs clean -- %f
 filter.lfs.process=git-lfs filter-process
 filter.lfs.required=true
 filter.lfs.smudge=git-lfs smudge -- %f
-gc.autopacklimit=40
 index.sparse=false
 init.defaultbranch=master
-lfs.allowincompletepush=1
 lfs.fetchrecentalways=true
-lfs.repositoryformatversion=0
-log.excludedecoration=refs/prefetch/
-maintenance.auto=false
-maintenance.strategy=incremental
 merge.stat=false
 oh-my-zsh.hide-dirty=1
 oh-my-zsh.hide-status=1
exit 1

The ones with - prefix are the configs exclusive to the internal repo.

Do you have any troubleshooting commands that I can run?

[tummychow]

well, to be blunt, there's nothing i can do without a repo that repros the segfault, period. i can't give you a command that just demonstrates the problem, because it's a segfault. you could get a core dump out of the segfault, but then you'd have to gdb into it yourself, which would be a miserable experience for most people (i just finished gdbing something for a glib2 issue and i wouldn't wish it on my enemies - no offense to glib2). i would rather we find the segfault reproducer and file a bug for the libgit2 people to gdb into. the git config is almost certainly not relevant to the issue (libgit2 tends to lag behind actual git in its config support, so new features have no impact on libgit2), although i'd test the internal repo with the git config from the working repo just to be sure.

if the repo is internal and you can't dump the whole thing on the internet, you're going to have to find a way to trim the reproducer down to something artificial that you can share with me. keep in mind that git-absorb only looks at the commits in the stack (ie the commits that are exclusive to your branch) plus the index state. you don't need to give me the entire repo. i would focus on the content of those things and try to find the smallest of each that reproduces the issue:

• eg if your index has 3 hunks in it when you run git-absorb and you get a segfault, try running git-absorb with only one of the three hunks and see if that also segfaults.
• then repeat for the other hunks etc until you find the unique set of hunks that segfault.
• then go through the commits in the stack and see which ones don't overlap with the hunks in the index - you should be able to discard those commits from the history entirely and still reproduce the segfault.
• then try shrinking the hunks in each commit until you can find the fewest number that still reproduce the segfault.
• then try replacing the actual code in each commit with something else and see if it still segfaults.
• try making an empty new repo and creating hunks with the same line offsets as the repro case but with garbage code that isn't private, and see if that still segfaults.
• etc.