Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #16209

Re: process substitution fd lifetime race condition

Show key headers only | View raw

On Mon, Apr 20, 2020 at 3:58 PM Chet Ramey <chet.ramey@case.edu> wrote:
> OK, good. It was either that or closing the fd after reaping the child
> process -- I couldn't tell 100% from the system call trace.

The latter is an interesting possibility. I assume SIGCHLD comes in
through a signal handler, so it's asynchronous, which means it could
race. But in the case that fd 63 hasn't already been closed, wont
subsequent fifos use different fds, which means the signal handler
doesn't need to synchronize with anything?

Either way, glad to hear that your patch fixes the issue. Looking
forward to the release of 5.0.017.

It seems like process substitution fifo lifetime is really tricky. You
can't really reference track, since the path is just a string that
could be manipulated. So how do you know when it's safe to clean up
that fd and that nobody is using it? I suppose you have a set of
lexical heuristics that fit for "most common cases"? And I guess those
are undocumented and can't really be relied upon since evidently they
do change.

I wonder if one general improvement would be to never close a fifo if
it has data in it, but it's read position is still at zero.

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: process substitution fd lifetime race condition "Jason A. Donenfeld" <Jason@zx2c4.com> - 2020-04-20 16:02 -0600

csiph-web