[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How to check for SIGABRT?
From: |
Eric Blake |
Subject: |
Re: How to check for SIGABRT? |
Date: |
Fri, 8 Dec 2017 16:25:02 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 |
On 12/08/2017 02:36 PM, Simon Sobisch wrote:
> We use the autoconf generated testsuite script in GnuCOBOL to test the
> compiler and runtime - and it works very well for "normal" tests.
>
> There are some tests where the compiler should abort and it does, but
> when it does so "correctly" by raising SIGABRT we can check for return
> code 134 but get an additional stderr message similar to
> "/full/path/to/testsuite.de/testcasenumber/run aborted on line 40" (and
> I don't know if SIGABRT will result in return code 134 on all "exotic"
> systems).
POSIX says that SIGABRT is 6 on XSI systems, but you can be compliant
with POSIX without being an XSI system (but non-XSI systems tend to not
run autoconf). However, your bigger problem is that on ksh, SIGABRT
shows up in $? as 262 (it specifically treats signals as 256+num instead
of 128+num, to make signals unambiguous with normal exit status).
>
> The following options come to mind:
>
> * use `trap` in AT_CHECK to catch the error if it is the expected result
> --> should fix the additional stderr, we still would have to check for
> return code 134
Your trap could then exit (normally) with a known exit status, rather
than reusing the inherited status that may or may not be 134. Or even
write to a witness file, ignore the value of $? altogether, and do a
second AT_CHECK that the witness file was touched.
> Do you have any experience/thoughts about this?
> Is there any "best practice" (ideally as official documentation) for
> checking signals in the autoconf generated testsuite script?
Expecting death to a signal is unusual, so I don't know of anyone else
doing it. But if it is a common enough paradigm, I agree that making it
easier in autotest to check that a process died due to a particular
signal may be a worthwhile enhancement.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature