From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdK5q-0000yG-9k for qemu-devel@nongnu.org; Fri, 17 May 2013 08:49:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UdK5o-0000TA-V7 for qemu-devel@nongnu.org; Fri, 17 May 2013 08:49:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UdK5o-0000SA-N7 for qemu-devel@nongnu.org; Fri, 17 May 2013 08:49:04 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4HCn2BV008105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 May 2013 08:49:02 -0400 Message-ID: <5196273C.8070800@redhat.com> Date: Fri, 17 May 2013 09:49:00 -0300 From: Lucas Meneghel Rodrigues MIME-Version: 1.0 References: <1368780720-14852-1-git-send-email-stefanha@redhat.com> <87obcaaq4b.fsf@blackfin.pond.sub.org> <20130517100738.GF2342@redhat.com> In-Reply-To: <20130517100738.GF2342@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] tests: set MALLOC_PERTURB_ to expose memory bugs List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Markus Armbruster , Stefan Hajnoczi , qemu-devel@nongnu.org On 17/05/13 07:07 AM, Daniel P. Berrange wrote: >> 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. > > 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. Indeed. I've never thought about it, thanks for sharing the insight.