[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] iotests: disable core dumps in test 061
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH] iotests: disable core dumps in test 061 |
Date: |
Thu, 24 Sep 2015 12:07:13 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 24.09.2015 um 08:45 hat Markus Armbruster geschrieben:
> Max Reitz <address@hidden> 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 <address@hidden>
> >> ---
> >> 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