Re: [Qemu-devel] [PATCH] tests: set MALLOC_PERTURB_ to expose memory bugs

[Lucas Meneghel Rodrigues <lmr@redhat.com>]

On 17/05/13 07:58 AM, Markus Armbruster wrote:
> "Daniel P. Berrange" <berrange@redhat.com> writes:
>
>> On Fri, May 17, 2013 at 11:54:12AM +0200, Markus Armbruster wrote:
>>> Stefan Hajnoczi <stefanha@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 <stefanha@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.

That's a pretty great idea, Markus. I'm going to implement it in 
virt-test, thanks!