os/signal: `TestTerminalSignal` failing on `linux-s390x-ibm` as of CL 440220

[bcmills]

https://build.golang.org/log/59c45ddde98d0d3c660c381aa819fa1a5b85e154:

session leader error: error setting tty process group: no such processerror running second subprocess: error setting tty process group: no such process
--- FAIL: TestTerminalSignal (0.01s)
    signal_cgo_test.go:186: Sending ^Z...
    signal_cgo_test.go:195: error reading readiness: EOF
FAIL
FAIL	os/signal	1.782s

TestTerminalSignal was rewritten in https://go.dev/cl/440220 to make direct system calls.
It appears that the call that is failing is an ioctl with argument TIOCSPGRP.
It could possibly be caused by an invalid return from syscall.Getpgrp().

(attn @golang/s390x; CC @prattmic)

[bcmills]

Hmm, looks like a similar failure mode on linux-mips-rtrk too.
https://build.golang.org/log/b10d790868d55f5ab0c97753619052684ef73a92:

session leader error: error setting tty process group back: no such processerror running second subprocess: error setting tty process group back: no such process
--- FAIL: TestTerminalSignal (0.06s)
    signal_cgo_test.go:186: Sending ^Z...
    signal_cgo_test.go:195: error reading readiness: EOF
FAIL
FAIL	os/signal	3.224s

(attn @golang/mips)

[gopherbot]

Change https://go.dev/cl/443066 mentions this issue: os/signal: add missing newlines to TestTerminalSignal

[prattmic]

I tried to take a quick look at this on a linux-s390x gomote, but that builder apparently doesn't have strace installed. :(

[jonathan-albrecht-ibm]

I tried to take a quick look at this on a linux-s390x gomote, but that builder apparently doesn't have strace installed. :(

@prattmic I've installed strace on all the s390x builders if you can try again

[prattmic]

Awesome, thanks. @bcmills was right that the ioctl argument is incorrect (at least on s390x, still waiting on mips buildlet):

1185859 getpgid(0 <unfinished ...>
1185859 <... getpgid resumed>)          = 1185859
1185859 ioctl(3, TIOCSPGRP, [0] <unfinished ...>
1185859 <... ioctl resumed>)            = -1 ESRCH (No such process)

[0] should be [1185859].

Is there an ABI difference for ioctl arguments on s390x? That seems like the most obvious cause, though I don't see evidence of that in ioctl calls in syscall or x/sys or from a quick glance at the Linux source.

I'm going to send a CL to skip this test on s390x for now.

[prattmic]

On MIPS, this failure actually occurs on the second ioctl call, the first is fine. On that buildlet, strace doesn't know how to read the argument, but it looks like it is correct:

16007 1665778506.336427 write(2, "child pid: 16014 0x910000\n", 26 <unfinished ...>
16007 1665778506.336497 <... write resumed> ) = 26
16007 1665778506.336578 ioctl(3, TIOCSPGRP, 0x910000) = -1 ESRCH (No such process)
16007 1665778506.336837 write(2, "session leader error: error setting tty process group back: no such process\n", 76) = 76
16007 1665778506.336963 kill(16014, SIGKILL) = 0
16019 1665778506.337100 +++ killed by SIGKILL +++
16018 1665778506.337130 +++ killed by SIGKILL +++
16015 1665778506.337163 +++ killed by SIGKILL +++
16017 1665778506.337188 +++ killed by SIGKILL +++
16007 1665778506.337221 waitid(P_PID, 16014,  <unfinished ...>
16016 1665778506.338067 +++ killed by SIGKILL +++
16014 1665778506.338121 +++ killed by SIGKILL +++
16007 1665778506.338145 <... waitid resumed> {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=16014, si_uid=0, si_status=SIGKILL, si_utime=0, si_stime=0}, WEXITED|WNOWAIT, NULL) = 0
16007 1665778506.338224 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=16014, si_uid=0, si_status=SIGKILL, si_utime=0, si_stime=0} ---

0x910000 is the address of pgid 16014, so that seems OK.

PID 16014 clearly exists, given that we successfully kill it, though perhaps it isn't a valid PGID, but it looks like it should:

16014 1665778506.195828 setpgid(0, 0 <unfinished ...>
16014 1665778506.195873 <... setpgid resumed> ) = 0

man 2 setpgid: "setpgid() sets the PGID of the process specified by pid to pgid. If pid is zero, then the process ID of the calling process is used. If pgid is zero, then the PGID of the process specified by pid is made the same as its process ID."

Thus, I think this is a different bug from s390x.