processT251 failure (fd 0 considered special?)

[blackgnezdo]

When running on OpenBSD 7.2 as a part of my attempt to test ghc HEAD I ran into a failure which is easier to observe standalone:

% ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.2.4
% ghc ~/s/ghc/libraries/process/tests/processT251.hs -o /tmp/z
ghc ~/s/ghc/libraries/process/tests/processT251.hs -o /tmp/z
[1 of 1] Compiling Main             ( /home/greg/s/ghc/libraries/process/tests/processT251.hs, /home/greg/s/ghc/libraries/process/tests/processT251.o )
Linking /tmp/z ...
% /tmp/z
parent start
child start
processT251: ./processT251: createProcess: close: invalid argument (Bad file descriptor)
z: user error (Pattern match failure in 'do' block at /home/greg/s/ghc/libraries/process/tests/processT251.hs:20:5-15)
% 

Tracing the syscalls is a bit tedious but boils down to these salient parts:

 46520 processT251 GIO   fd 1 wrote 13 bytes
       "parent start
       "
 46520 processT251 CALL  pipe(0x7f7ffffca5e8)
 46520 processT251 STRU  int [2] { 3, 4 }
 46520 processT251 RET   pipe 0
 46520 processT251 CALL  vfork()
 89659 processT251 RET   vfork 0
 89659 processT251 CALL  execve(0x224e040f0,0x224e04158,0x7f7ffffce9a8)
 89659 processT251 NAMI  "./processT251"
 89659 processT251 ARGS  
	[0] = "./processT251"
	[1] = "child"
 46520 processT251 RET   vfork 89659/0x15e3b
...
 89659 processT251 GIO   fd 1 wrote 12 bytes
       "child start
       "
 89659 processT251 RET   write 12/0xc
 89659 processT251 CALL  pipe(0x7f7ffffec6f8)
 89659 processT251 STRU  int [2] { 0, 3 }      ---------------------------------- [1]
 89659 processT251 RET   pipe 0
 89659 processT251 CALL  vfork()

 23176 processT251 RET   vfork 0
 23176 processT251 CALL  close(0)               ----------------------------------[2]
 23176 processT251 RET   close 0
 23176 processT251 CALL  fcntl(3,F_SETFD,FD_CLOEXEC)
 23176 processT251 RET   fcntl 0
...
 23176 processT251 CALL  close(0)              -----------------------------------[3]
 23176 processT251 RET   close -1 errno 9 Bad file descriptor
 23176 processT251 CALL  write(3,0x7f7ffffec628,0x8)
 23176 processT251 GIO   fd 3 wrote 8 bytes
       "\M-h\M^Z \0\0\0\0\0"
 23176 processT251 RET   write 8
 23176 processT251 CALL  write(3,0x7f7ffffec634,0x4)
 23176 processT251 GIO   fd 3 wrote 4 bytes
       "	\0\0\0"

So the "child" is PID 89659.
[1] "child" gets a pipe with a pair of descriptors [0, 3]
[2] "child2" closes fd0 successfully once
[3] "child2" fails to close fd0 the second time (it's no longer open)

Maybe there's an expectation somewhere that pipe won't allocate these FDs because they are reserved? I don't think they are per any standard and since "child" already wanted to run with std_in = NoStream, its wish is fulfilled and fd=0 is used otherwise.

[blackgnezdo]

@bgamari just in case you haven't noticed this.

[bgamari]

Thanks for the ping, @blackgnezdo, as well as the useful analysis.

Indeed this is tricky. I believe the pipe in step (1) is the forkCommunication pipe:

process/cbits/posix/fork_exec.c

Line 122 in 383181f

int r = pipe(forkCommunicationFds);

child2 then closes the parent's end of the pipe:

process/cbits/posix/fork_exec.c

Line 171 in 383181f

close(forkCommunicationFds[0]);

and then attempts to close stdin (which we assume is fd 0) again:

process/cbits/posix/fork_exec.c

Line 230 in 383181f

setup_std_handle_fork(STDIN_FILENO, stdInHdl, forkCommunicationFds[1]);

It's not clear what to do about this. We could in principle not call close on a standard fd if it shares an identity with on of the ends of the pipe. However, that then poses the question of what should be done in the other two cases: STD_HANDLE_USE_FD and STD_HANDLE_USE_PIPE. Specifically, attempting to execute either of these two cases will result in the communications pipe being clobbered, meaning that we lose the ability to report failures.

I suspect the right way to handle this is to ensure that the communications pipe does not inhabit fds 0 through 2 by calling dup after pipe creation when necessary.