Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Zsh 3.1.6 still hangs on for loops utilizing lots of stdout
- X-seq: zsh-workers 9565
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: Zsh 3.1.6 still hangs on for loops utilizing lots of stdout
- Date: Fri, 4 Feb 2000 13:30:53 +0100 (MET)
- Cc: Clint Olsen <olsenc@xxxxxxxxxxxxxxxx>
- In-reply-to: Alexandre Duret-Lutz's message of 04 Feb 2000 10:24:30 +0100
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Alexandre Duret-Lutz wrote:
> >>> "Clint" == Clint Olsen <olsenc@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author