Re: [PATCH 0/2] test results for v1.7.12-rc0 on cygwin
René Scharfe wrote: Am 28.07.2012 20:46, schrieb Ramsay Jones: Unfortunately, I was unable to reproduce the final failure in t7810-grep.sh. I tried, among other things, to provoke a failure thus: $ for i in $(seq 100); do if ! ./t7810-grep.sh -i -v; then break; fi done $ but, apart from chewing on the cpu for about 50 minutes, it didn't result in a failure. :( However, after looking at test 59, it seems to me to be a stale (redundant) test. So, patch #2 removes that test! :-D [I wish I could reproduce the failure because I don't like not knowing why it failed, but ...] Removing the test makes sense, since it was needed for --ext-grep only, is relatively expensive and a bit fragile (by depending on MAXARGS). Indeed. I'm slightly worried about the non-reproducible failure, though. Yep, me too. Perhaps a timing issue is involved and chances are higher if you leave out the option -v? Yes, one of the among other things I tried was to drop the -v, but the end result was the same. Also, since I have DEFAULT_TEST_TARGET=prove in my config.mak, I tried: $ for i in $(seq 100); do if ! prove --exec sh t7810-grep.sh; then break; fi done $ But again, it didn't provoke a failure (it did run quite a bit faster ...). I have now run this test file in excess of 600 times without failure in the last two evenings (taking about 5-6 hours wallclock time). [I haven't come remotely close to running the test-suite 600 times on cygwin in the last 6 years ...] So, I'm out of ideas (and will stop trying to reproduce the failure). ATB, Ramsay Jones -- 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
Re: [PATCH 0/2] test results for v1.7.12-rc0 on cygwin
Am 28.07.2012 20:46, schrieb Ramsay Jones: Unfortunately, I was unable to reproduce the final failure in t7810-grep.sh. I tried, among other things, to provoke a failure thus: $ for i in $(seq 100); do if ! ./t7810-grep.sh -i -v; then break; fi done $ but, apart from chewing on the cpu for about 50 minutes, it didn't result in a failure. :( However, after looking at test 59, it seems to me to be a stale (redundant) test. So, patch #2 removes that test! :-D [I wish I could reproduce the failure because I don't like not knowing why it failed, but ...] Removing the test makes sense, since it was needed for --ext-grep only, is relatively expensive and a bit fragile (by depending on MAXARGS). I'm slightly worried about the non-reproducible failure, though. Perhaps a timing issue is involved and chances are higher if you leave out the option -v? Thanks, René -- 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
Re: [PATCH 0/2] test results for v1.7.12-rc0 on cygwin
René Scharfe rene.scha...@lsrfire.ath.cx writes: Am 28.07.2012 20:46, schrieb Ramsay Jones: Unfortunately, I was unable to reproduce the final failure in t7810-grep.sh. I tried, among other things, to provoke a failure thus: $ for i in $(seq 100); do if ! ./t7810-grep.sh -i -v; then break; fi done $ but, apart from chewing on the cpu for about 50 minutes, it didn't result in a failure. :( However, after looking at test 59, it seems to me to be a stale (redundant) test. So, patch #2 removes that test! :-D [I wish I could reproduce the failure because I don't like not knowing why it failed, but ...] Removing the test makes sense, since it was needed for --ext-grep only, is relatively expensive and a bit fragile (by depending on MAXARGS). I'm slightly worried about the non-reproducible failure, though. Perhaps a timing issue is involved and chances are higher if you leave out the option -v? Thanks for a comment. I agree that removing the test makes sense, and I also agree that the non reproducibleness is worrying (the latter is more important). -- 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