qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] iotests: disable core dumps in test 061


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] iotests: disable core dumps in test 061
Date: Thu, 24 Sep 2015 08:45:32 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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.

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.

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.

Possible alternative: normalize the crash message differences before
diffing against golden output.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]