Strange behaviour on 'read' from a pipe
Hello,
I have this script, that I've found to never write "DONE" in my systems, with
bash 4.0, 4.1, 4.2.. until 4.2-p20, my last test.
However, in irc some people told me it prints DONE for them. If I run the
script with
bash under 'strace -f', it also prints DONE.
So there is some kind of race in 'read'. The current program output in my
computer is:
reading
debug:done
If 'read' unblocked by error (SIGCHLD?), it would print reading again. If
'read' unblocked having read nothing, it would print a newline (it does not).
And of course it does not print the 'DONE' either.
Maybe it's me not understanding something? I suspect that 'read' reacts to
EINTR, and tries to read again, with the error of *reopening the pipe*
(<$PIPE), which will make it block forever.
Here the script:
---
#!/var/run/current-system/sw/bin/bash
PIPE=/tmp/pipe
rm -f $PIPE
mkfifo $PIPE
function spawn {
"$@"
echo debug:done
echo DONE > $PIPE
}
spawn sleep 1 &
while true; do
echo reading
while read LINE < $PIPE; do
echo $LINE
exit 0
done
done
-
Regards,
Lluís.
Re: Bash segmentation fault on startup/ssh
On 3/30/12 3:42 PM, Nitz wrote: > Machine Type: i386-redhat-linux-gnu > > Bash Version: 4.1 > Patch Level: 2 > Release Status: release > > Description: > > I am getting a segmentation fault from bash when I try to SSH to a > remote server (running RHEL 4.4.5-6). After providing my credentials, > the SSH client spits back the "Last login: ..." information, and then > just hangs. If you can reproduce the crash using gdb, gdb bash and run -x and look at the command trace. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Bash segmentation fault on startup/ssh
Hi Chet, I was able to solve the problem; I had accidentally set my bashrc file to source itself upon startup, which caused the segmentation fault. Changing the file fixed the problem as far as I can tell. Thanks for following up. Thanks, Nick On Mar 31, 2012, at 8:51 PM, Chet Ramey wrote: > On 3/30/12 3:42 PM, Nitz wrote: > >> Machine Type: i386-redhat-linux-gnu >> >> Bash Version: 4.1 >> Patch Level: 2 >> Release Status: release >> >> Description: >> >> I am getting a segmentation fault from bash when I try to SSH to a >> remote server (running RHEL 4.4.5-6). After providing my credentials, >> the SSH client spits back the "Last login: ..." information, and then >> just hangs. > > If you can reproduce the crash using gdb, gdb bash and run -x and look at > the command trace. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Strange behaviour on 'read' from a pipe
On 3/31/12 9:19 AM, Lluís Batlle i Rossell wrote: > Hello, > > I have this script, that I've found to never write "DONE" in my systems, with > bash 4.0, 4.1, 4.2.. until 4.2-p20, my last test. > > However, in irc some people told me it prints DONE for them. If I run the > script with > bash under 'strace -f', it also prints DONE. It looks like a simple race condition. I suspect that the scheduler arranges things so that the child process ends up exiting between the open and the read, but I don't have any real evidence to back it up. (Like you, my Mac OS X system prints `DONE'.) You might want to try using exec to open the FIFO in the parent process rather than trying to open it on each read. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
