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

From: Jeff King <peff@peff.net>
Date: Mar 9, 2013, 04:48 UTC
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:

Show 7 quoted lines

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