From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 759 invoked from network); 4 Feb 2000 12:37:39 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Feb 2000 12:37:39 -0000 Received: (qmail 22522 invoked by alias); 4 Feb 2000 12:37:29 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9565 Received: (qmail 22504 invoked from network); 4 Feb 2000 12:37:26 -0000 Date: Fri, 4 Feb 2000 13:30:53 +0100 (MET) Message-Id: <200002041230.NAA24341@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk CC: Clint Olsen In-reply-to: Alexandre Duret-Lutz's message of 04 Feb 2000 10:24:30 +0100 Subject: Re: Zsh 3.1.6 still hangs on for loops utilizing lots of stdout Alexandre Duret-Lutz wrote: > >>> "Clint" == Clint Olsen 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