Re: Zsh 3.1.6 still hangs on for loops utilizing lots of stdout

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Alexandre Duret-Lutz wrote:

> >>> "Clint" == Clint Olsen <olsenc@ichips.intel.com> writes:
> 
> [...]
> 
>  Clint> for file in *.something
>  Clint> do
>  Clint>   cat $file
>  Clint> done > /tmp/concat
> 
>  Clint> The number of files matched were probably in the thousand or so
>  Clint> range, each with about 10 lines of data.  Zsh hangs on large jobs
>  Clint> like this to the point of having to kill the window entirely (^C
>  Clint> doesn't work, neither does ^Z).

I've tried it now under DU and Linux but can't reproduce it. I can
understand that it is hard (even seemingly impossible) to stop such a
loop with ^Z because you have to hit one of the cats (and then those
animal-rights people will get you and... er, no), which can be
difficult if they finish very quickly. However, ^C should work even
then -- and it does for me.

We had some patches for the execution, jobs and signal code but most
of them were before the 3.1.6 release and I don't think any of those
that came afterwards should have changed this.

Hm, don't have an idea how this can happen.

> I have seen this on linux too (and attributed to
> my kernel, wich is making `Oops' sometimes...) 
> when making a loop of the form :
> 
> for i in *.wav
> do
>   8hz-mp3 $i $i:r.mp3
> done
> 
> *.wav did match only about 20 files, and the xterm disapeared
> after the second or third file processed.  Although the xterm 
> is dead, zsh and 8hz are still alive (but waiting) :
> 
>   PID  PPID WCHAN  COMMAND
>  3533  6548 signal zsh
>  3587  3533 down_f 8hz-mp3 audio_12.wav audio_12.mp3
> 
> (I never saw that `down_f' flag before)
> 
> If I attach to 3533 to see where it wait I see
> 
> (gdb) bt
> #0  0x400ad8fa in sigsuspend () from /lib/libc.so.6
> ...
> 
> Don't know if it can help.
> 
> (And since you are guessing it maybe related to stdout output, I must
> state that 8hz is quite verbose too).

Well, we had some problems with IO and AIX but this stack trace looks
completely fine -- saying only that it's waiting for the 8hz-mp3.

In both cases: does it happen with other shells, too?

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de