Segfault during a big messy rebase

Segfault during a big messy rebase

[Greg Werbin]

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.

Re: Segfault during a big messy rebase

[Jeff King]

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

> 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.

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