From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zf3Qw-0007OR-07 for qemu-devel@nongnu.org; Thu, 24 Sep 2015 06:07:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zf3Qq-0005eR-VZ for qemu-devel@nongnu.org; Thu, 24 Sep 2015 06:07:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zf3Qq-0005eM-RI for qemu-devel@nongnu.org; Thu, 24 Sep 2015 06:07:16 -0400 Date: Thu, 24 Sep 2015 12:07:13 +0200 From: Kevin Wolf Message-ID: <20150924100713.GD4060@noname.redhat.com> References: <1443024701-32184-1-git-send-email-berto@igalia.com> <5602DE96.5070108@redhat.com> <8737y4uxgz.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8737y4uxgz.fsf@blackfin.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH] iotests: disable core dumps in test 061 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Alberto Garcia , qemu-devel@nongnu.org, Max Reitz Am 24.09.2015 um 08:45 hat Markus Armbruster geschrieben: > Max Reitz writes: > > > On 23.09.2015 18:11, Alberto Garcia wrote: > >> Commit 934659c460 disabled the supression of segmentation faults in > >> bash tests. The new output of test 061, however, assumes that a core > >> dump will be produced if a program aborts. This is not necessarily the > >> case because core dumps can be disabled using ulimit. > >> > >> We cannot guarantee that core dumps can be enabled in all cases, so we > >> should disable them completely and update the test output accordingly. > >> > >> Signed-off-by: Alberto Garcia > >> --- > >> tests/qemu-iotests/061 | 3 +++ > >> tests/qemu-iotests/061.out | 4 ++-- > >> 2 files changed, 5 insertions(+), 2 deletions(-) > > > > As noted in the commit message for > > 3f394472c5bca59de5cab9baafdff1984b0213a3, ulimit -c 0 does not work for > > everyone (for instance, for me it fails, probably because I'm using > > systemd's coredumpctl). Generally speaking, it'll only prevent a core > > dump from being created if your /proc/sys/kernel/core_pattern points to > > a file, but it won't if it points to a program for gathering the dump. > > > > What we really want is to use "sigraise $(kill -l KILL)" instead of > > "abort", because SIGKILL never creates a core dump, but will have > > basically the same effect of crashing qemu-io. > > No, we don't want that. SIGABRT gives the user the option to have core > dumps. By switching to SIGKILL, you'd take away that option. Why do you need a core dump for a test case that intentionally simulates a crash without any actual misbehaviour causing it? Isn't it actually annoying to get useless core dumps? > Because modern systems have complicated the ways you can get and not get > core dumps, user qemu-iotests is having difficulties getting one > reliably. Since it's just as fine with getting none reliably, and a > reliably way to ask for that still exists (ulimit -c 0), it could do > just that. If you reread Max' email carefully, his very point is that 'ulimit -c 0' is _not_ reliable. > Inconvenience: when a test fails, you can't examine its core dump > anymore, but have to instrument the test to create one, or splice in > gdb, or whatever else it takes. On the other hand, you don't have to > delete core dumps anymore. If we switched the intentional crash to SIGKILL, you could still get core dumps for cases where there is actual misbehaviour without touching the script. 'ulimit -c 0' in contrast, in addition to not being reliable, is all or nothing. > Possible alternative: normalize the crash message differences before > diffing against golden output. Extending _filter_qemu_io is another viable option to make the test pass, yes. However, you would still need to manually delete core dumps from the intentional crash. Kevin