Re: Multio deadlock (Re: multios doesn't work with 2>&1)

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Sun, 27 Oct 2013 12:39:17 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> Does the following look right?  It does fix the deadlock, but we might
> call close() on an already closed fd, which it appears this is trying
> to avoid (maybe so as not to change errno?).
> 
> diff --git a/Src/exec.c b/Src/exec.c
> index 99c7eaa..7ac1ad5 100644
> --- a/Src/exec.c
> +++ b/Src/exec.c
> @@ -3372,7 +3372,7 @@ execcmd(Estate state, int input, int output, int how, int last1)
>  	 * hairy.
>  	 */
>  	for (i = 0; i < 10; i++)
> -	    if (fdtable[i] != FDT_UNUSED)
> +	    if (i < 3 || fdtable[i] != FDT_UNUSED)
>  		close(i);
>  	closem(FDT_UNUSED);
>  	if (thisjob != -1)

Hmm... why don't we initialise fdtable[0..2] to FDT_INTERNAL at boot?  I
can see we don't, since from a shell soon after start I get

(gdb) p fdtable[0]@11
$6 = "\000\000\000\000\000\000\000\000\000\000\001"

(FDT_UNUSED = 0, FDT_INTERNAL = 1).  However, I've alsoe looked later
and seen all three set to FDT_INTERNAL; not sure where that happens but
presumably something to do with redir.  Shouldn't we just initialise
them properly?

We could in principle detect if they're open by attempting to dup() and
seeing what fd we get.  Not sure if that's worth it, but it might be
cleaner.

pws