semantic: 0.090
performance: 0.081
device: 0.078
other: 0.077
PID: 0.077
graphic: 0.077
permissions: 0.074
files: 0.071
debug: 0.068
socket: 0.067
network: 0.065
KVM: 0.065
vnc: 0.056
boot: 0.054
debug: 0.246
files: 0.229
PID: 0.079
semantic: 0.076
other: 0.063
device: 0.056
network: 0.038
permissions: 0.035
socket: 0.035
performance: 0.034
vnc: 0.033
boot: 0.029
KVM: 0.024
graphic: 0.023

O_CLOEXEC not handled in dup3 system call in user mode

In qemu user mode, for hppa and sparc64 targets, the parameter of the dup3 is not passed correctly when it contains the O_CLOEXEC flag.

When the attached program runs, the expected output is:
errno=9=EBADF

How to reproduce on hppa:
- Compile the program: hppa-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-hppa
- Set environment variables for running qemu-hppa.
- ~/inst-qemu/2.9.0/bin/qemu-hppa testdup3-hppa
errno=22=EINVAL
testdup3.c:54: assertion 'errno == EBADF' failed

How to reproduce on sparc64:
- Compile the program: sparc64-linux-gnu-gcc-5 -O -Wall -static testdup3.c -o testdup3-sparc64
- Set environment variables for running qemu-sparc64.
- ~/inst-qemu/2.9.0/bin/qemu-sparc64 testdup3-sparc64
errno=22=EINVAL
testdup3.c:54: assertion 'errno == EBADF' failed







I see this bug for hppa, sparc64.
I don't see it for m68k, mips, mips64, powerpc, powerpc64.
Most likely because the binary values of O_CLOEXEC on hppa and sparc64 are different than on other platforms. Looking in the glibc source code:

$ grep -r 'define.*O_CLOEXEC' glibc
glibc/bits/fcntl.h:# define O_CLOEXEC   0x00400000      /* Set close_on_exec.  */
glibc/sysdeps/mach/hurd/bits/fcntl.h:# define O_CLOEXEC 0x00400000 /* Set FD_CLOEXEC.  */
glibc/sysdeps/unix/sysv/linux/sparc/bits/fcntl.h:#define __O_CLOEXEC    0x400000 /* Set close_on_exit.  */
glibc/sysdeps/unix/sysv/linux/bits/fcntl-linux.h:# define __O_CLOEXEC   02000000
glibc/sysdeps/unix/sysv/linux/bits/fcntl-linux.h:# define O_CLOEXEC     __O_CLOEXEC     /* Set close_on_exec.  */
glibc/sysdeps/unix/sysv/linux/hppa/bits/fcntl.h:#define __O_CLOEXEC     010000000 /* Set close_on_exec.  */
glibc/sysdeps/unix/sysv/linux/microblaze/bits/fcntl.h:#define __O_CLOEXEC        02000000       /* Set close_on_exec.  */
glibc/sysdeps/unix/sysv/linux/alpha/bits/fcntl.h:#define __O_CLOEXEC    010000000 /* Set close_on_exec.  */
glibc/sysdeps/nacl/bits/fcntl.h:# define O_CLOEXEC      02000000        /* Set close_on_exec.  */

So, what's missing is probably that the O_CLOEXEC of the target platform gets mapped to O_CLOEXEC of the host platform, during the dup3 system call emulation.

The behaviour in qemu-2.10 is the same as in qemu-2.9.

The behaviour in qemu-2.11 is the same as in qemu-2.9.

Should be fixed by http://patchwork.ozlabs.org/patch/849226/


Fix has been included here:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=10fa993aae539fa8d0da1d

Confirmed: It's fixed in qemu-2.12.