[Bug 295965] wait3(&status, WNOHANG, ...) clobbers status to -65536 when no child exits.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D295965

            Bug ID: 295965
           Summary: wait3(&status, WNOHANG, ...) clobbers status to -65536
                    when no child exits.
           Product: Base System
           Version: 15.1-RELEASE
          Hardware: arm
               URL: https://github.com/python/cpython/issues/151019#issuec
                    omment-4663777690
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: [email protected]
          Reporter: [email protected]
                CC: [email protected], [email protected]

Created attachment 271653
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D271653&action=
=3Dedit
test program to demonstrate ARMv7 wait3(WNOHANG) issue

Greetings,

we've been looking over various self-test failures in Python 3.15.0beta2 (in
ports) and on a particular system, and apparently FreeBSD 15.1-RC* clobber =
the
"status" field that we point wait3(...WNOHANG...) to when it doesn't have an
exited child to report the status of.  See URL.  The issue occurs in an ARM=
v7
poudriere jail hosted on Aarch64 on a Neoverse-N1 virtual server, and I can
reproduce it on Aarch64 with test code compiled with cc -m32.

int status =3D 0;
struct rusage ru; // uninit, will be cleared later if pid =3D=3D 0
pid_t pid =3D wait3(&status, WNOHANG, &ru);

At this point, pid =3D=3D 0 and status =3D=3D -65536 on ARMv7 or with -m32,=
 but not
Aarch64.
The latter is unexpected, and should be status =3D 0.

I am attaching a test program.

#0: It works on ARM64 and mostly everywhere else:
$ cc -std=3Dc11 -o try try-wait3.c -O3 -Wall && ./try
pid =3D 0, status =3D 0 =3D        0

That's the expected outcome. wait3() has nothing to report, and leaves stat=
us
and ru alone.

#1: Now add -m32 to the command line:
$ cc -std=3Dc11 -m32 -o try try-wait3.c -O3 -Wall && ./try
pid =3D 0, status =3D -65536 =3D 0xffff0000

=3D> OOPS.

To spice things up - truss "fixes" the status field but spoils the rusage
reporting:
$ truss ./try
fork()                                           =3D 58606 (0xe4ee)
freebsd32_wait4(-1,{ EXITED,val=3D0 },WNOHANG,{
u=3D0.000000,s=3D0.000000,in=3D4294958518,out=3D-39440684688344 }) =3D 0 (0=
x0)
freebsd32_fstat(1,{ mode=3Dcrw--w---- ,inode=3D108,size=3D0,blksize=3D4096 =
}) =3D 0 (0x0)
freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGN=
ED(12),-1,0x0)
=3D 537174016 (0x2004a000)
[...]
freebsd32_mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON|MAP_ALIGN=
ED(12),-1,0x0)
=3D 537210880 (0x20053000)
freebsd32_ioctl(1,TIOCGETA,0xffffcf68)           =3D 0 (0x0)
pid =3D 0, status =3D 0 =3D        0
write(1,"pid =3D 0, status =3D 0 =3D        0\n",31)   =3D 31 (0x1f)
kill(58606,SIGTERM)                              =3D 0 (0x0)
_exit(0x0)=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
process exit, rval =3D 0

The same happens if I set up an armv7 poudriere jail, enter it, and then
compile the test program there (with or without -m32 does not make a differ=
ence
obviously, the test fails every time unless run under truss).

--=20
You are receiving this mail because:
You are the assignee for the bug.=