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
> 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
> Heres the output of the GIT_TRACE file
> trace: built-in: git 'apply' '--index'
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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html