On Sat, Jan 12, 2008 at 04:04:32AM -0500, Jeff King wrote:
I couldn't reproduce this just running the test, but running it under
valgrind showed a memory access error. Fix is below.
BTW, this could have been caught automagically if we had valgrind
integration in the test scripts. Below is a rudimentary patch to do so.
I'm not that familiar with valgrind, so input from those more
knowledgeable is appreciated, and maybe we can get something official
post-1.5.4.
You can use it like "./t7300-clean.sh -m"; each call to 'git' is run
through valgrind, and returns an error if the original program had an
error, or if valgrind turned up any errors.
It of course runs horribly slowly. I've just kicked off a
make GIT_TEST_OPTS='-i -m'
now. A few caveats:
- It barfs on _any_ valgrind error. On my Debian unstable system,
anything that touches nss ends up with an error deep in the dlopen
code. Therefore to make this useful, I had to put
{
dl hack
Memcheck:Addr4
obj:/lib/ld-2.7.so
}
into /usr/lib/valgrind/default.supp
We should maybe have a 'git.supp' error suppression file, but in this
case, the error really seems to be platform-specific.
- We only catch calls to 'git', not 'git-foo' (and in fact for that
reason this doesn't catch the t7300 bug by itself, since that uses
git-clean). A follow-on patch will deal with this.
---
t/test-lib.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 90b6844..415e918 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -84,6 +84,8 @@ do
--no-python)
# noop now...
shift ;;
+ -m|--m|--me|--mem|--memc|--memch|--memche|--memchec|--memcheck)
+ alias git='memcheck git'; shift ;;
*)
break ;;
esac
@@ -120,6 +122,12 @@ say () {
say_color info "$*"
}
+memcheck() {
+ valgrind -q --error-exitcode=1 --leak-check=no "$@" && return 0
+ echo >&2 valgrind failure: "$@"
+ return 1
+}
+
test "${test_description}" != "" ||
error "Test script did not set test_description."
--
1.5.4.rc3.1.g027628-dirty