From: Jeff King <peff@peff.net>
Date: Sat, 09 Mar 2013 04:48:50 GMT
Subject: Re: Memory corruption when rebasing with git version 1.8.1.5 on arch
Message-ID: <20130309044850.GB12167@sigill.intra.peff.net>
In-Reply-To: <513A7D80.5000501@bernhard-posselt.com>

On Sat, Mar 09, 2013 at 01:08:32AM +0100, Bernhard Posselt wrote:

> >The problem is likely happening in a sub-command of git-pull, so
> >valgrind isn't reporting it. Can you try re-running with
> >"valgrind --trace-children=yes", or alternatively narrow down the
> >problematic command by setting GIT_TRACE=1 in the environment?
>
> Heres the output with GIT_TRACE=1, the valgrind log has 4000 lines.
> If you should still require the valgrind log, please tell me.

Hmm, the GIT_TRACE output was less clear than I had hoped; it's unclear
to me which git program is actually dying (my guess is "git apply", and
we are squelching stderr, which is where the GIT_TRACE output is going).

Can you try it once again with something like GIT_TRACE=/tmp/foo.out,
which will make sure we record the trace directly, even if stderr ends
up redirected?

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?

-Peff