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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html