Re: [PATCH 0/6] --valgrind improvements
On Thu, May 16, 2013 at 10:50:11PM +0200, Thomas Rast wrote: One open issue with the last patch that currently eludes me: if I combine --valgrind-parallel with any --valgrind=*, there are lots of errors as (apparently) the valgrind wrapper setups race against each other. However, without any --valgrind=* (thus defaulting to 'memcheck') this doesn't happen. I noticed two racy error messages. If you do: cd t make clean ./some-test --valgrind-parallel=8 you will get complaints from mkdir about existing directories, as we use mkdir as a poor man's O_EXCL to create lockfiles. These error messages are harmless (we loop and try again), and we should perhaps just squelch the stderr from mkdir. Although that might make weird situations hard to diagnose, like another error that prevents creating the lockfile, so maybe it is better to just live with the extra output (after the directory is built once, it does not happen at all). I also notice: $ ./t4052-* --valgrind-parallel=8 --valgrind=memcheck ... ./t4052-stat-output.sh: 572: ./test-lib.sh: cannot open /home/peff/compile/git/t/valgrind/bin/git-send-email.perl: No such file Line 572 is checking the #! line of the _source_ file. So it shouldn't be checking t/valgrind/bin in the first place. It looks like it comes from this loop: for path in $PATH do ls $path/git-* 2 /dev/null | while read file do make_valgrind_symlink $file done done as t/valgrind/bin seems to be in the $PATH of the parallel sub-processes. Hmm. It looks like you set up the valgrind dir in the parent test process, and _then_ call the sub-processes in parallel. We shouldn't need to do any valgrind setup at all in the subprocesses, should we? They would just be replicating what the parent already did. -Peff -- 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
[PATCH 0/6] --valgrind improvements
Peff and me discussed improving the usability of --valgrind testing. In particular, two ideas that came up were options for running only a subset of the tests in a file under --valgrind, and for running a single test script under valgrind while exploiting parallelism. So here's a little series. It goes like this: test-lib: enable MALLOC_* for the actual tests Fix for an unrelated bug that I came across. test-lib: refactor $GIT_SKIP_TESTS matching test-lib: verbose mode for only tests matching a pattern test-lib: valgrind for only tests matching a pattern An option --valgrind-only=patterns that lets you run only the subtest matching patterns under valgrind. test-lib: allow prefixing a custom string before ok N etc. test-lib: support running tests under valgrind in parallel An option --valgrind-parallel=n to run n instances in parallel, each of which runs every n-th test under valgrind, staggered so that they cover everything. It's a bit of a hack, and thus RFC, but gives decent results. On my 2-core laptop I measured a just over 2x speedup. On a 6-core it starts falling off because of the extra (non-valgrind) runs, resulting in a 4.8x speedup. One open issue with the last patch that currently eludes me: if I combine --valgrind-parallel with any --valgrind=*, there are lots of errors as (apparently) the valgrind wrapper setups race against each other. However, without any --valgrind=* (thus defaulting to 'memcheck') this doesn't happen. Thomas Rast (6): test-lib: enable MALLOC_* for the actual tests test-lib: refactor $GIT_SKIP_TESTS matching test-lib: verbose mode for only tests matching a pattern test-lib: valgrind for only tests matching a pattern test-lib: allow prefixing a custom string before ok N etc. test-lib: support running tests under valgrind in parallel t/README | 10 +++ t/test-lib.sh | 175 - t/valgrind/valgrind.sh | 3 + 3 files changed, 156 insertions(+), 32 deletions(-) -- 1.8.3.rc2.393.g8636c0b -- 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
