On 17/05/13 08:15 AM, Stefan Hajnoczi wrote:
On Fri, May 17, 2013 at 11:54 AM, Markus Armbruster <arm...@redhat.com> 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))
Covered in the commit description:
"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."
I didn't want to clutter output with "MALLOC_PERTURB_=123" on every
run. AFAIK we have no log where this can be silently stashed. I
guess we could write it to a file and add that to .gitignore.
Yes, you could consider to have a debug log or something similar.
