posix_spawn() will have the same problem. Unfortunately, we have to
follow the POSIX semantics which say that all file descriptors must
first be duplicated by the child and only then those marked as close-
on-exec are closed.
The QNX spawn() call does not follow these semantics and is therefore
not prone to this issue.

--Elad

On Fri, 2018-01-19 at 18:35 +0000, Roger Maclean wrote:
> My guess is that this represents a race condition resulting from
> simultaneous forking and opening new pipes.  A pipe/open call is not
> atomic and involves creating a connection (i.e. calling
> ConnectAttach) and
> sending messages to the remote side to complete the operation.  I
> suspect
> that as soon as the connection is made, any fork will attempt to dup
> the
> connection but until the remaining process completes the dup will
> fail.
> 
> If this is the case (and even if not), you would do better to use
> posix_spawn instead of fork/exec.  Besides being faster (due to fewer
> processes being created), it will bypass the problem since fds are
> marked
> close on exec until the connection is complete.
> 
> Or perhaps you want to have a mutex around some of this if only to
> allow
> some control over what fds are given out to other processes.
> 
> 
> On 2018-01-19, 1:19 PM, "Jason Fordham" <community-noreply@qnx.com>
> wrote:
> 
> > 
> > Hi Elad,
> > 
> > > 
> > > A multi-threaded fork() is open to all kinds of issues, and until
> > > recently was not permitted at all. That said, I don't see why it
> > > would
> > > be a pipe() call that ends up returning EBADF.
> > Do you happen to know how recently this changed? Is it possible
> > that it's
> > not been fully exercised in the field, and this is a Bug?
> > 
> > > 
> > > In which context does the code you provided run? The parent or
> > > the
> > > child?
> > Each thread runs the exec, in a loop. Same code in each thread. The
> > child
> > process is just cat, so it's not doing much beyond writing the
> > content of
> > the file passed as its argument  to stdout.
> > 
> > Kind regards,
> > Jason
> > 
> > 
> > 
> > _______________________________________________
> > 
> > OSTech
> > http://community.qnx.com/sf/go/post118412
> > To cancel your subscription to this discussion, please e-mail
> > ostech-core_os-unsubscribe@community.qnx.com
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post118413
> To cancel your subscription to this discussion, please e-mail ostech-
> core_os-unsubscribe@community.qnx.com

Hi Roger,

> My guess is that this represents a race condition resulting from
> simultaneous forking and opening new pipes.  A pipe/open call is not
> atomic and involves creating a connection (i.e. calling ConnectAttach) and
> sending messages to the remote side to complete the operation.  I suspect
> that as soon as the connection is made, any fork will attempt to dup the
> connection but until the remaining process completes the dup will fail.

This is an interesting theory: I hope what I am about to say doesn't invalidate it.  We are certainly thinking that 
there is a race condition. We now have a native repro which uses vfork, and we'd like to share it with you.

What I had thought was an issue with pipe() turns out to be an issue with the vfork failing: there was a remapping of 
the exception detail in the ThrowIOException function, which I didn't expect and didn't check. So that was misleading to
 everyone: I'm sorry about that. We've now correctly located the errno=9 as coming from the vfork.

> If this is the case (and even if not), you would do better to use
> posix_spawn instead of fork/exec.  Besides being faster (due to fewer
> processes being created), it will bypass the problem since fds are marked
> close on exec until the connection is complete.

What we are working on is a port of OpenJDK, and the code we are concerned with is the native implementation of java.
lang.UNIXProcess.forkAndExec(). There is commentary that explains why Linux uses vfork, and others posix_spawn: vfork is
 clearly preferred, because posix_spawn needs a helper process - which adds to the number of processes.

The complexity of switching to the posix_spawn implementation means we do not have a standalone repro: however, we have 
shown (in a crude way, using a hardcoded child path) that posix_spawn has the same issues as vfork. We should have a 
cleaner build tomorrow.

One of the remarks in the commentary is that on Linux, many of the paths through posix_spawn use vfork, because that's 
how it's implemented in glibc. Is the QNX implementation of posix_spawn based on the glibc implementation? If so, that 
might be an alternative explanation of why we see the same behavior when using posix_spawn 

> Or perhaps you want to have a mutex around some of this if only to allow
> some control over what fds are given out to other processes.

Would you like to look at the standalone repro? 

Kind regards,
Jason