Getting unexpected error from piping "read -d"

Getting unexpected error from piping "read -d"

[Bart Schaefer]

This is a strange one, it only happens with "read -d" (change delimiter)
and only when piping the output.  It's present as far back as 4.3.11.

torch% read -d '' | head
zsh: bad tcgets: bad file descriptor

GDB trace from the current source is appended.

Incidentally, the oldest tagged version of zsh I can build from git is
4.3.10.  Any version 4.3.9 or older that I tried, generates pre-build
errors such as bad configure.ac files or failure to complete mkmakemod.
I suspect tags were incompletely or incorrectly applied when importing
from CVS.


(gdb) where
#0  gettyinfo (ti=0x816c780) at ../../zsh-5.0/Src/utils.c:1519
#1  0x080822eb in update_job (jn=0x87de894) at ../../zsh-5.0/Src/jobs.c:488
#2  0x080b6299 in wait_for_processes () at ../../zsh-5.0/Src/signals.c:512
#3  0x080b6493 in zhandler (sig=17) at ../../zsh-5.0/Src/signals.c:594
#4  <signal handler called>
#5  0x0086e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#6  0x008afe8c in sigsuspend () from /lib/tls/libc.so.6
#7  0x080b603e in signal_suspend (sig=17, wait_cmd=0)
    at ../../zsh-5.0/Src/signals.c:375
#8  0x08084b41 in zwaitjob (job=1, wait_cmd=0) at ../../zsh-5.0/Src/jobs.c:1454
#9  0x08084d1a in waitjobs () at ../../zsh-5.0/Src/jobs.c:1499
#10 0x0806372f in execpline (state=0xbffe4f90, slcode=17410, how=18, last1=0)
    at ../../zsh-5.0/Src/exec.c:1554
#11 0x08062c33 in execlist (state=0xbffe4f90, dont_change_job=0, exiting=0)
    at ../../zsh-5.0/Src/exec.c:1261
#12 0x08062686 in execode (p=0xb7d3f6d0, dont_change_job=0, exiting=0, 
    context=0x813c803 "toplevel") at ../../zsh-5.0/Src/exec.c:1070
#13 0x0807d612 in loop (toplevel=1, justonce=0) at ../../zsh-5.0/Src/init.c:185
#14 0x08080927 in zsh_main (argc=2, argv=0xbffe50e4)
    at ../../zsh-5.0/Src/init.c:1625
#15 0x0804c0a6 in main (argc=2, argv=0xbffe50e4) at ../../zsh-5.0/Src/main.c:93

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

[Bart Schaefer]

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.

That stack trace is wrong.  Please ignore it; sorry.

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

[Bart Schaefer]

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.

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

[Bart Schaefer]

On Aug 30,  4:17pm, Bart Schaefer wrote:
}
} #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
} 
} 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.

The problem with that theory being that there hasn't been an exec() in
the branch where bin_read() runs.

Anyway, the following seems to fix this, and I can't see how it can be
incorrect in any case:


diff --git a/Src/exec.c b/Src/exec.c
index 5ad957f..bf50d0f 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -3569,8 +3569,11 @@ closem(int how)
 
     for (i = 10; i <= max_zsh_fd; i++)
 	if (fdtable[i] != FDT_UNUSED &&
-	    (how == FDT_UNUSED || fdtable[i] == how))
+	    (how == FDT_UNUSED || fdtable[i] == how)) {
+	    if (i == SHTTY)
+		SHTTY = -1;
 	    zclose(i);
+	}
 }
 
 /* convert here document into a here string */