On Mon, May 10, 2021 at 01:28:44AM +0200, Bruno Haible wrote:
> On Haiku (32-bit), compiling m4-1.4.18b+fixes works fine, but one of the tests
> fails:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Checking ../../checks/198.sysval
> @ ../doc/m4.texi:6749: Origin of test
> ../../checks/198.sysval: stdout mismatch
> --- m4-tmp.10743/m4-xout 2021-05-10 01:15:42.526647296 +0000
> +++ m4-tmp.10743/m4-out 2021-05-10 01:15:42.504102912 +0000
> @@ -1,6 +1,6 @@
>
> -2304
> +5376
>
> 0
>
> -2304
> +5376
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> 2304 is 0x0900, whereas 5376 is 0x1500.
>
> On this platform, the signal number 0x09 is SIGKILL, and the signal
> number 0x15 is SIGKILLTHR. I can reproduce it also in the shell:
> When you kill a process with signal 9, bash reports not "Killed"
> but "Kill Thread", and 'echo $?' prints not 137 but 149.
Thanks for the report. The test already acknowledges that testing
sysval is inherently difficult:
@comment This test has difficulties being portable, even on platforms
@comment where syscmd invokes /bin/sh. Kill is not portable with signal
@comment names. According to autoconf, the only portable signal numbers
@comment are 1 (HUP), 2 (INT), 9 (KILL), 13 (PIPE) and 15 (TERM). But
@comment all shells handle SIGINT, and ksh handles HUP (as in, the shell
@comment exits normally rather than letting the signal terminate it).
@comment Also, TERM is flaky, as it can also kill the running m4 on
@comment systems where /bin/sh does not create its own process group.
@comment And PIPE is unreliable, since people tend to run with it
@comment ignored, with m4 inheriting that choice. That leaves KILL as
@comment the only signal we can reliably test.
@example
dnl This test assumes kill is a shell builtin, and that signals are
dnl recognizable.
ifdef(`__unix__', ,
`errprint(` skipping: syscmd does not have unix semantics
')m4exit(`77')')dnl
I suppose our only recourse is to figure out a way to skip the test on
Haiku by testing whether kill -9 actually results in signal 9 from the
shell's perspective, prior to attempting it from m4's perspective.
What does this output for you on the affected platform?
$ /bin/sh -c '/bin/sh -c "kill 9 \$\$"; echo $?'
$ (SHELL=ksh; $SHELL -c "$SHELL"' -c "kill -9 \$\$" 2>/dev/null; echo $?')
It is 137 (bash, most other shells) or 265 (ksh) on GNU/Linux (and
presumably all other systems that don't have SIGKILLTHR); I'm guessing
that for you it will output 143. If so, I can then enhance the test
to test what shell death will report prior to testing what m4 sees
from shell death.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
