"Daniel P. Berrange" <berra...@redhat.com> writes: > On Fri, May 17, 2013 at 11:54:12AM +0200, Markus Armbruster wrote: >> Stefan Hajnoczi <stefa...@redhat.com> writes: >> >> > glibc wipes malloc(3) memory when the MALLOC_PERTURB_ environment >> > variable is set. The value of the environment variable determines the >> > bit pattern used to wipe memory. For more information, see >> > http://udrepper.livejournal.com/11429.html. >> > >> > Set MALLOC_PERTURB_ for gtester and qemu-iotests. Note we always set >> > the environment variable to 1 so the test is deterministic. Setting a >> > random variable might expose more bugs but would be harder to reproduce. >> > >> > Both make check and qemu-iotests pass with MALLOC_PERTURB_ enabled. >> > >> > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> >> > --- >> > Lucas noticed KVM autotest failures when enabling MALLOC_PERTURB_. By >> > enabling >> > it for in-tree test suites we can detect memory management errors earlier. >> > >> > tests/Makefile | 4 +++- >> > tests/qemu-iotests/check | 2 +- >> > 2 files changed, 4 insertions(+), 2 deletions(-) >> > >> > diff --git a/tests/Makefile b/tests/Makefile >> > index a307d5a..25f6d28 100644 >> > --- a/tests/Makefile >> > +++ b/tests/Makefile >> > @@ -171,6 +171,7 @@ GCOV_OPTIONS = -n $(if $(V),-f,) >> > $(patsubst %, check-qtest-%, $(QTEST_TARGETS)): check-qtest-%: >> > $(check-qtest-y) >> > $(if $(CONFIG_GCOV),@rm -f *.gcda */*.gcda */*/*.gcda */*/*/*.gcda,) >> > $(call quiet-command,QTEST_QEMU_BINARY=$*-softmmu/qemu-system-$* \ >> > + MALLOC_PERTURB_=1 \ >> > gtester $(GTESTER_OPTIONS) -m=$(SPEED) >> > $(check-qtest-$*-y),"GTESTER $@") >> > $(if $(CONFIG_GCOV),@for f in $(gcov-files-$*-y); do \ >> > echo Gcov report for $$f:;\ >> >> If you want punishment, why not go for extra punishment? >> >> MALLOC_PERTURB_=$(($RANDOM % 255 + 1)) > > That could lead to non-reproducable failures though. I think it is better > to use a fixed value so that you're more likely to be able to reproduce > the issue every time you run the tests.
A fixed value misses failures. A random value is just as reproducible as a fixed one, simply use the same value. Requires the value to be logged, of course. > Rather than setting MALLOC_PERTURB_=1 unconditionally in the Makefile > though, it ought to honour any existing MALLOC_PERTURB_ env variable > the user has set. That could let automated test harness run repeatedly > with random MALLOC_PERTURB_, while still giving a deterministic value > for developers by default. Yes, we should respect the user's MALLOC_PERTURB_.