Re: bug with eval, proc-subst and pipes

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jul 16,  9:55pm, Peter Stephenson wrote:
}
} On Mon, 15 Jul 2013 10:06:24 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > 
} > It's a race condition of some kind.  I can reproduce reliably with
} > 
} > % (){ sleep 5; paste "$@" } <(echo 1)
} > 
} > even without an "eval".
} 
} That's not a race; it looks like it because it relies on a command
} running before the one that's using the command substitution, but in
} fact the bug in this case is completely deterministic.  It may therefore
} be a different problem from Stephane's.

I don't think so, fundamentally.  The problem in both cases is that the
file descriptor for the process substitution is closed before the data
is read.  This has the unintended side-effect of removing the special
device file.  The reasons for the premature descriptor close may be
different, but the end result is the same; I believe fixing either one
would fix both.

If, instead, a fifo file created by zsh itself is used, it's not removed 
until the associated job is deleted from the job table.

} At line 2864 of exec.c, as it's in the function that's calling sleep,
} it closes all the file descriptors of type FDT_PROC_SUBST that it
} thinks are private to the sleep. Unfortunately as fdtable is global
} it has no way of knowing that actually fd 11 is associated with the
} current function, not the sleep, so it closes it anyway.

I think you've just explained why simply moving the closem() call is
not sufficient.
 
} I suppose a smarter way of marking such file descriptors is needed,
} perhaps one associated with the appropriate job in the same way as
} auxiliary processes are remembered.  Good luck avoiding leaks...

Not in the way auxiliary processes are remembered; in the way temporary
files are remembered.  With #undef PATH_DEV_FD, zsh seems to do a very
good job of cleaning up those FIFOs.