Re: *** glibc detected *** git: double free or corruption (fasttop): 0x0000000001fab820 ***

[Jeff King <peff@peff.net>]

On Tue, Jun 04, 2013 at 11:46:55AM -0400, Jason Gross wrote:

> I get "*** glibc detected *** git: double free or corruption
> (fasttop): 0x0000000001fab820 ***" reliably on the following set of
> commands.  I'm working on a remote machine where I don't have
> administrative privileges, so I can't update from git 1.7.2.5 to a
> newer version.  I figured I'd report it, even though I haven't checked
> to see if it still happens in a newer version of git.

Yes, it's fixed. You can test such things even without administrative
access. For example:

  # get git
  git clone git://git.kernel.org/pub/scm/git/git.git
  cd git

  # set up our test case
  git clone git://github.com/JasonGross/barnowl.git
  (cd barnowl && git checkout git-bug)

  # now make an easy-to-run test we can run on each commit; make sure
  # to use bin-wrappers, as it sets up everything to run git out of the
  # current build, overriding anything in your $PATH
  cat >test <<\EOF
  #!/bin/sh
  make -j16 &&
  cd barnowl &&
  ../bin-wrappers/git shortlog >/dev/null &&
  echo OK
  EOF
  chmod +x test

  # now confirm our old version is broken
  git checkout v1.7.2.5
  ./test

  # and check that a new version works
  git checkout v1.8.3
  ./test

You can even use git-bisect to find out which commit fixed it. We have
to "reverse" our test, though, since bisect is usually about finding
regressions, not fixes.

  # create reverse test
  cat >revtest <<\EOF
  #!/bin/sh
  ./test && exit 1
  exit 0
  EOF
  chmod +x revtest

  # set up our bisect; again, our good/bad are reversed because we are
  # treating the fix as a "bug"
  git bisect start
  git bisect good v1.7.2.5
  git bisect bad v1.8.3

  # and now we can let "bisect run" do all the hard work while we drink
  # an ice-cold beverage
  git bisect run ./revtest

If we did everything right, this should yield the commit with the fix.
And it turns up d8d2eb7 (mailmap: fix use of freed memory, 2010-10-11),
which seems likely (and reading the full commit message, details the
exact case you have).

And then we can use "git tag --contains" to find out which releases have
it:

  $ git tag --contains d8d2eb7 | grep ^v | grep -v -- -rc | head -1
  v1.7.10

So you'd need to go to v1.7.10 to fix it.

-Peff