From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29240 invoked from network); 4 Feb 2000 09:26:03 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 4 Feb 2000 09:26:03 -0000 Received: (qmail 26020 invoked by alias); 4 Feb 2000 09:25:58 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9556 Received: (qmail 26013 invoked from network); 4 Feb 2000 09:25:58 -0000 To: zsh-workers@sunsite.auc.dk Cc: Clint Olsen Subject: Re: Zsh 3.1.6 still hangs on for loops utilizing lots of stdout References: <20000203104548.A25426@ichips.intel.com> X-Attribution: adl From: Alexandre Duret-Lutz Date: 04 Feb 2000 10:24:30 +0100 In-Reply-To: Clint Olsen's message of "Thu, 3 Feb 2000 10:45:48 -0800" Message-ID: User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>> "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 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 #1 0x80991bc in signal_suspend (sig=17, sig2=0) at ../../last/Src/signals.c:343 #2 0x8077e03 in waitjob (job=2, sig=0) at ../../last/Src/jobs.c:886 #3 0x8077f57 in waitjobs () at ../../last/Src/jobs.c:916 #4 0x805eabe in execpline (state=0xbffff6d0, slcode=2562, how=18, last1=0) at ../../last/Src/exec.c:986 #5 0x805e0b9 in execlist (state=0xbffff6d0, dont_change_job=1, exiting=0) at ../../last/Src/exec.c:766 #6 0x807dd1e in execfor (state=0xbffff6d0, do_exec=0) at ../../last/Src/loop.c:134 #7 0x806240e in execcmd (state=0xbffff6d0, input=0, output=0, how=18, last1=2) at ../../last/Src/exec.c:2109 #8 0x805f39b in execpline2 (state=0xbffff6d0, pcode=131, how=18, input=0, output=0, last1=0) at ../../last/Src/exec.c:1119 #9 0x805e682 in execpline (state=0xbffff6d0, slcode=6146, how=18, last1=0) at ../../last/Src/exec.c:915 #10 0x805e0b9 in execlist (state=0xbffff6d0, dont_change_job=0, exiting=0) at ../../last/Src/exec.c:766 #11 0x805df66 in execode (p=0x40015278, dont_change_job=0, exiting=0) at ../../last/Src/exec.c:712 #12 0x8072a3d in loop (toplevel=1, justonce=0) at ../../last/Src/init.c:150 #13 0x805138c in main (argc=1, argv=0xbffff7c4) at ../../last/Src/main.c:89 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). [...] -- Alexandre Duret-Lutz