Max Reitz <mre...@redhat.com> 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 <be...@igalia.com> >> --- >> 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.
