Re: bug with named pipes and process substitution

[Peter Stephenson <p.stephenson@xxxxxxxxxxx>]

On Tue, 21 Jul 2015 17:25:15 -0700
Petros Aggelatos <petrosagg@xxxxxxxxx> wrote:
> I encountered a bug when running the following two commands:
> 
> mkfifo test_pipe
> echo 1 | tee >(cat > test_pipe) | paste - test_pipe
> 
> In bash and zsh 5.0.2 it outputs "1 1" and then exits. In zsh 5.0.8
> however, it outputs the same thing and hangs forever.

Thanks.  I can tell you roughly what's going on, but not the
answer.  We used to be fairly cavalier with handling file descriptors
for process substitutions, not closing them in the right place.  In the
patch you mention...

> I bisected the repo for the commit that introduced this behaviour and
> it was introduced in 3c5732223f65309c6820f15b8519f674bd21185b which
> includes the patch from this thread
> http://www.zsh.org/mla/workers/2013/msg00569.html

...we instead put them on a linked list to be removed when the job is
completed, which is better targeted.  However, it leaves the potential
for holes.  Commit aede5c52bf557f89d1d09fa5430186af6e295241 is also
relevant as it plugged some of those holes.  It appears there's at least
one more.

The specific difficulty here is that the "tee" is in a forked subshell
which is exec'd.  Because the process substitution is an argument to the
tee, it needs to be able to see the fd in the file system (e.g.
/proc/self/fd/15 when I tried it).  In the forked shell we can't close
the fd because we've lost control by the time it's needed.  However, we
need to close it in the parent shell before we fork anything else, in
time to ensure other processes don't hang because of it.

The call we need is probably pipecleanfilelist(...) from the second
commit, if we can find where to put it...

pws