On Thu, Jul 29, 2010 at 11:40:01PM +0200, Thomas Rast wrote: > Doing the following on current next (v1.7.2.1-230-g75e8ac1) stops > after a number of iterations, usually within 5 minutes: > > while GIT_SKIP_TESTS="t0025.[5-9] t0025.??" \ > ./t0025-crlf-auto.sh --valgrind --root=/dev/shm --tee -i > do > : > done I was able to reproduce after many iterations on my debian unstable box, too. What's odd to me is that valgrind reports no error. Which implies to me that it is actually a race condition that is being triggered by how slow valgrind makes us run, but not an actual memory error. > I tried patching them in this way: > > ---- 8< ---- > diff --git i/t/t0025-crlf-auto.sh w/t/t0025-crlf-auto.sh > index f5f67a6..d7424c9 100755 > --- i/t/t0025-crlf-auto.sh > +++ w/t/t0025-crlf-auto.sh > @@ -48,8 +48,7 @@ test_expect_success 'crlf=true causes a CRLF file to be normalized' ' > > # Note, "normalized" means that git will normalize it if added > has_cr two && > - twodiff=`git diff two` && > - test -n "$twodiff" > + test_must_fail git diff --exit-code two I also tried doing instead: test -n "$twodiff" || bash -i which dumped me with a shell in the "broken" state. The interesting thing is that I can then repeatably run "git diff two" and get an empty diff. So I don't think the error or race condition is in the run of "git diff" itself, but rather what happened above (presumably the in the read-tree step). > So... does anyone have any ideas what to test next? Or what might > cause this? Sorry, I am also at a loss, but maybe those hints can help point you in the right direction. The next step for me would be to try running just the read-tree bit in a loop to see if you can get anomalous results. -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