Segfault during a big messy rebase

I was in the middle of a big messy rebase when the following happened:

$ git rebase --continue /usr/local/Cellar/git/2.9.0/libexec/git-core/git-rebase--interactive: line 238: 60305 Segmentation fault: 11 "$@" Could not commit staged changes.

And then I tried:

$ git rebase --abort fatal: Unable to create '/Users/greg/my-project/.git/MERGE_RR.lock': File exists.

Another git process seems to be running in this repository, e.g. an editor opened by 'git commit'. Please make sure all processes are terminated then try again. If it still fails, a git process may have crashed in this repository earlier: remove the file manually to continue.

Then I ran:

$ rm .git/MERGE_RR.lock $ git rebase --abort No rebase in progress?

Which left the branch in a kind of half-rebased limbo, and my only option was to put it out of its misery and delete it. Fortunately I had backed up my work to a different branch, so recovery was not a problem.

I don't know where to look inside Git for diagnostic logs; let me know if there's anything I can add to help track down the issue.

On Mon, Jun 27, 2016 at 06:51:26AM +0000, Greg Werbin wrote:

Can you reproduce this segfault if you run the rebase again?

It's hard to tell what command even had a problem (one can guess "git commit" from the message). Running it with GIT_TRACE=1 would show more details.

The simplest way to debug a segfault is generally to get a core file and ask gdb for the backtrace. On Linux, that is generally:

  # turn on cores; most modern distros turn them off by default
  ulimit -c unlimited

  # run your command
  git rebase ...

  # now find the core file; it's dumped in the cwd of the command
  # that segfaulted, which is probably either .git or the top of the
  # worktree
  core=$(find . -name core)

  # and then ask gdb for the backtrace
  gdb -ex backtrace git $(core)

I see you have /usr/local/Cellar, which IIRC is a homebrew thing. Some of those commands may need adjusting on OS X.

-Peff