Re: How to check for SIGABRT?

[Eric Blake]

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