CVS commit: src/tests/lib/libc/sys

["Taylor R Campbell" <riastradh%netbsd.org@localhost>]

Module Name:    src
Committed By:   riastradh
Date:           Fri Oct  2 15:43:09 UTC 2026

Modified Files:
        src/tests/lib/libc/sys: t_sigio.c

Log Message:
t_sigio: Add diagnostics to fillpipebuf.

For some reason, on some of the releng testbeds, in
socket_local_write_shutdown (and only socket_local_write_shutdown),
it's putting only 7168 (= 8192 - 1024) bytes into a local socket's
buffer before write fails with EAGAIN, but then _after_ fillpipebuf
has returned, write succeeds:

filled 4 with 7168 bytes
[thread] waiting for barrier
[thread] giving other thread a head start
checking that write fails with 35 (Resource temporarily unavailable)...
*** Check failed: /tmp/build/2026.10.02.08.45.07-i386/src/tests/lib/libc/sys/t_sigio.c:368: Expected true value in (nwrit = write(writefd, &c, 1)) == -1
*** Check failed: /tmp/build/2026.10.02.08.45.07-i386/src/tests/lib/libc/sys/t_sigio.c:369: nwrit != -1: nwrit=1
[thread] shutdown(SHUT_RD)
[thread] shutdown

But on my machine, and presumably on other testbeds where the test
passes, it fills the whole 8192 bytes before EAGAIN, and the next
write after fillpipebuf fails with EAGAIN as expected.

It's possible that with sndlowat=2048, the last write in fillpipebuf
should fail because we've dropped below 2048 bytes free by the time
we hit 7168 bytes.  But why would the _next_ write, _after_
fillpipebuf has returned, succeed?  And why would it be different on
some platforms

Testbeds where it has been failing:
- alpha
- armv7
- i386
- macppc
- sparc
- sparc64
- vax

Testbeds where it has been passing:
- amd64
- aarch64
- riscv-riscv64

XXX Should maybe have only one fillpipebuf between the various tests
that use it.


To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/tests/lib/libc/sys/t_sigio.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.