Re: Memory corruption when rebasing with git version 1.8.1.5 on arch

[Jeff King <peff@peff.net>]

On Sat, Mar 09, 2013 at 11:54:36AM +0100, Bernhard Posselt wrote:

> >Also, I can almost reproduce here, as PatrickHeller/core.git is public.
> >However, I suspect the problem is particular to your work built on top,
> >which looks like it is at commit 0525bbd73c9015499ba92d1ac654b980aaca35b2.
> >Is it possible for you to make that commit available on a temporary
> >branch?

> What do you mean exactly by that?

I just meant to push the work from your local repository somewhere where
I could access it to try to replicate the issue. What you did here:

> git clone https://github.com/Raydiation/memorycorruption
> cd memorycorruption
> git pull --rebase https://github.com/Raydiation/core

...should be plenty. Unfortunately, I'm not able to reproduce the
segfault.  All of the patches apply fine, both normally and when run
under valgrind.

> Heres the output of the GIT_TRACE file
> [...]
> trace: built-in: git 'apply' '--index' '/srv/http/owncloud/.git/rebase-apply/patch'

This confirms my suspicion that the problem is in "git apply".

You had mentioned before that the valgrind log was very long.  If you're
still able to reproduce, could you try running it with valgrind like
this:

  valgrind -q --trace-children=yes --log-file=/tmp/valgrind.out \
    git pull --rebase https://github.com/Raydiation/core

Logging to a file instead of stderr should mean we still get output for
commands that are invoked with their stderr redirected (which is the
case for the "git apply" in question), and using "-q" should eliminate
the uninteresting cruft from the log.

-Peff