Re: Getting unexpected error from piping "read -d"

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Aug 30,  3:08pm, Bart Schaefer wrote:
}
} torch% read -d '' | head
} zsh: bad tcgets: bad file descriptor
} 
} GDB trace from the current source is appended.

Here's a more sensible backtrace:

#0  gettyinfo (ti=0xbff0a5f0) at ../../zsh-5.0/Src/utils.c:1526
#1  0x0805c0d9 in bin_read (name=0xb7d58700 "read", args=0xb7d58760, 
    ops=0xbff0a7d0, func=0) at ../../zsh-5.0/Src/builtin.c:5367
#2  0x0804ca91 in execbuiltin (args=0xb7d586d0, bn=0x814fc24)
    at ../../zsh-5.0/Src/builtin.c:450
#3  0x08068450 in execcmd (state=0xbff0b030, input=0, output=12, how=18, 
    last1=0) at ../../zsh-5.0/Src/exec.c:3274
#4  0x08064228 in execpline2 (state=0xbff0b030, pcode=611, how=18, input=0, 
    output=0, last1=0) at ../../zsh-5.0/Src/exec.c:1743
#5  0x0806335b in execpline (state=0xbff0b030, slcode=9218, how=18, last1=0)
    at ../../zsh-5.0/Src/exec.c:1478
#6  0x08062c33 in execlist (state=0xbff0b030, dont_change_job=0, exiting=0)
    at ../../zsh-5.0/Src/exec.c:1261
#7  0x08062686 in execode (p=0xb7d58618, dont_change_job=0, exiting=0, 
    context=0x813c803 "toplevel") at ../../zsh-5.0/Src/exec.c:1070
#8  0x0807d612 in loop (toplevel=1, justonce=0) at ../../zsh-5.0/Src/init.c:185
#9  0x08080927 in zsh_main (argc=2, argv=0xbff0b184)
    at ../../zsh-5.0/Src/init.c:1625
#10 0x0804c0a6 in main (argc=2, argv=0xbff0b184) at ../../zsh-5.0/Src/main.c:93


Looks like SHTTY has become an invalid file descriptor in the child that
is forked to do the read.  Theoretically it should therefore have been
set to -1, but that didn't happen.  Looks like workers/27134 is the
culprit.

I tried removing the #ifndef from this bit of exec.c so that SHTTY is
set to -1:

    /*
     * Note that we don't close fd's attached to process substitution
     * here, which should be visible to external processes.
     */
    closem(FDT_XTRACE);
#ifndef FD_CLOEXEC
    if (SHTTY != -1) {
	close(SHTTY);
	SHTTY = -1;
    }
#endif
    child_unblock();

That did not resolve the problem, so the close-on-exec is not passing
through that branch.  However, it DID coincidentally cause the Test/A05
"5 seconds to fail" to hang for me, exactly twice before it went back
to succeeding every time again.  I'll send something in another thread.

In any case it's always going to be wrong for a background "read" (as
in one on the left side of a pipe) to try to muck with the TTY.  Even
if the descriptor were valid, it'd presumably TTIN or TTOU the job.