Re: zsh & make
On Wed, Apr 28, 2004 at 01:44:01PM -0700, Peter A. Castro wrote: >On Wed, 28 Apr 2004, Daniel Clausen wrote: > >> Hi > >Greetings, Daniel, > >> On Tuesday, April 27, 2004, at 05:55PM, Dave Korn <[EMAIL PROTECTED]> wrote: >> >> [snip] > >This is a rather interesting problem. It appears that this is, yet >another, variation on the fork() & signal handling problem. Something >we thought had been resolved in a snapshot a while ago. If I run your >little test with 'tree 4 4', then run the little cp script, I get >differing results, both if I re-run it and if I change "$line.1" to >"$line.xx". You'll notice that when the hang happens, it's usually >*after* the cp runs. A quick check of the shell's state shows it's >sitting in severals waits, some of which I'm not quite sure of why they >are there: This sure looks like a backtrace from an optimized, stripped Cygwin DLL. It is not too surprising if you get odd data from that. cgf >(gdb) thread 1 >[Switching to thread 1 (thread 258.0x10b)]#0 0x77f682cb in >ntdll!ZwWaitForMultipleObjects () from /d/WINNT/System32/NTDLL.DLL >(gdb) bt >#0 0x77f682cb in ntdll!ZwWaitForMultipleObjects () > from /d/WINNT/System32/NTDLL.DLL >#1 0x77f1ce6b in WaitForMultipleObjectsEx () > from /d/WINNT/system32/KERNEL32.DLL >#2 0x77f1cd76 in WaitForMultipleObjects () > from /d/WINNT/system32/KERNEL32.DLL >#3 0x610a5160 in cygwin1!__getreent () from /usr/bin/cygwin1.dll >#4 0x0022ebd0 in ?? () -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: zsh & make
On Wed, 28 Apr 2004, Daniel Clausen wrote: > Hi Greetings, Daniel, > On Tuesday, April 27, 2004, at 05:55PM, Dave Korn <[EMAIL PROTECTED]> wrote: > > [snip] This is a rather interesting problem. It appears that this is, yet another, variation on the fork() & signal handling problem. Something we thought had been resolved in a snapshot a while ago. If I run your little test with 'tree 4 4', then run the little cp script, I get differing results, both if I re-run it and if I change "$line.1" to "$line.xx". You'll notice that when the hang happens, it's usually *after* the cp runs. A quick check of the shell's state shows it's sitting in severals waits, some of which I'm not quite sure of why they are there: (gdb) info thread 5 thread 258.0x103 0x77f762e9 in ntdll!DbgSsInitialize () from /d/WINNT/System32/NTDLL.DLL 4 thread 258.0xfa 0x77f682db in ntdll!ZwWaitForSingleObject () from /d/WINNT/System32/NTDLL.DLL 3 thread 258.0xed 0x77f682cb in ntdll!ZwWaitForMultipleObjects () from /d/WINNT/System32/NTDLL.DLL 2 thread 258.0x11c 0x77f67f07 in ntdll!ZwReadFile () from /d/WINNT/System32/NTDLL.DLL * 1 thread 258.0x10b 0x77f682cb in ntdll!ZwWaitForMultipleObjects () from /d/WINNT/System32/NTDLL.DLL (gdb) thread 1 [Switching to thread 1 (thread 258.0x10b)]#0 0x77f682cb in ntdll!ZwWaitForMultipleObjects () from /d/WINNT/System32/NTDLL.DLL (gdb) bt #0 0x77f682cb in ntdll!ZwWaitForMultipleObjects () from /d/WINNT/System32/NTDLL.DLL #1 0x77f1ce6b in WaitForMultipleObjectsEx () from /d/WINNT/system32/KERNEL32.DLL #2 0x77f1cd76 in WaitForMultipleObjects () from /d/WINNT/system32/KERNEL32.DLL #3 0x610a5160 in cygwin1!__getreent () from /usr/bin/cygwin1.dll #4 0x0022ebd0 in ?? () (gdb) thread 3 [Switching to thread 3 (thread 258.0xed)]#0 0x77f682cb in ntdll!ZwWaitForMultipleObjects () from /d/WINNT/System32/NTDLL.DLL (gdb) bt #0 0x77f682cb in ntdll!ZwWaitForMultipleObjects () from /d/WINNT/System32/NTDLL.DLL #1 0x77f1ce6b in WaitForMultipleObjectsEx () from /d/WINNT/system32/KERNEL32.DLL #2 0x77f1cd76 in WaitForMultipleObjects () from /d/WINNT/system32/KERNEL32.DLL #3 0x61094197 in sigfillset () from /usr/bin/cygwin1.dll #4 0x610031a6 in getprogname () from /usr/bin/cygwin1.dll (gdb) thread 4 [Switching to thread 4 (thread 258.0xfa)]#0 0x77f682db in ntdll!ZwWaitForSingleObject () from /d/WINNT/System32/NTDLL.DLL (gdb) bt #0 0x77f682db in ntdll!ZwWaitForSingleObject () from /d/WINNT/System32/NTDLL.DLL #1 0x77f1cca0 in WaitForSingleObjectEx () from /d/WINNT/system32/KERNEL32.DLL #2 0x77f04f37 in WaitForSingleObject () from /d/WINNT/system32/KERNEL32.DLL #3 0x015c in ?? () #4 0x in ?? () (gdb) thread 5 [Switching to thread 5 (thread 258.0x103)]#0 0x77f762e9 in ntdll!DbgSsInitialize () from /d/WINNT/System32/NTDLL.DLL (gdb) bt #0 0x77f762e9 in ntdll!DbgSsInitialize () from /d/WINNT/System32/NTDLL.DLL #1 0x77f07039 in KERNEL32!DebugActiveProcess () from /d/WINNT/system32/KERNEL32.DLL #2 0x61003ee4 in getprogname () from /usr/bin/cygwin1.dll #3 0x0149f0e0 in ?? () There was one other alarming oddity, which is separate from this problem. cp, on occasion, would turn an existing file into a directory! I don't have any details, but it's independent of any shell, and very likely because my environment is not completely up to date. Anyway, the above looks suspiciously like the fork()/signal problem we thought was resolved earlier, where a parent would block on a read from a child, but when the child exist, the parent never gets notified. > > For debugging it, you might be able to get something useful like this: > > > >> COMPONENT_NAME = $(shell basename `pwd | tee i-was-here-.txt`) > > While trying to change our Makefiles the way you suggested, > I staggered over a bigger problem, which I tried to isolate > and make reproducable. > > The problem that occurs is that when reading lines over a pipe > and do something with them, zsh stops after some lines and > just hangs, while bash works w/o any problems. > > > The following script creates a primitive directory-tree structure > with a Makefile in every directory. > > #!/usr/bin/bash > # > # Usage: $0 > > if [ $# != 3 ] ;then >echo "Usage: " >exit 1 > fi > > n=0 > > while [ $n -lt $3 ] ;do >echo "Creating $1/$n" >mkdir $1/$n >echo "Hello" >$1/$n/Makefile > >if [ $2 -gt 1 ] ;then > $0 $1/$n $[$2-1] $3 >fi > >n=$[n+1] > done > # END OF SCRIPT > > > Invoke like this: > mkdir tree > ./createTree.sh tree 3 3 > > > Now, I execute this command: > > find tree -name Makefile | while read line ;do > echo $line > cp $line $line.1 > done > > > > When running this under zsh, it treats between 8 and 20 Makefiles and > then just hangs. (and I have to 'kill -9' the shell) Running it under > bash works just fine. (or try other "4 4" instead of "3 3" when creating > the tree-structure if by chance it treats all 27 Makefiles) > > > I think this shows the fundamen
RE: zsh & make
> -Original Message- > From: Daniel Clausen > Sent: 28 April 2004 10:34 > The problem that occurs is that when reading lines over a pipe > and do something with them, zsh stops after some lines and > just hangs, while bash works w/o any problems. > Now, I execute this command: > > find tree -name Makefile | while read line ;do > echo $line > cp $line $line.1 > done > When running this under zsh, it treats between 8 and 20 Makefiles and > then just hangs. (and I have to 'kill -9' the shell) Running it under > bash works just fine. (or try other "4 4" instead of "3 3" > when creating > the tree-structure if by chance it treats all 27 Makefiles) I tried this under zsh: [EMAIL PROTECTED] /artimi/firmware> zsh [EMAIL PROTECTED] \w> while read line ; do while> echo XX $line XX while> ls $line while> done fred XX fred XX ls: fred: No such file or directory As you can see, it read one line. It then locks up completely solid: no response to keys, no response to Ctrl-C/Z/D. I'm somewhat out-of-date with cygwin dll and apps, which probably explains why I see it fail immediately after one line and you see it get several lines. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: zsh & make
Hi On Tuesday, April 27, 2004, at 05:55PM, Dave Korn <[EMAIL PROTECTED]> wrote: [snip] > For debugging it, you might be able to get something useful like this: > >> COMPONENT_NAME = $(shell basename `pwd | tee i-was-here-.txt`) While trying to change our Makefiles the way you suggested, I staggered over a bigger problem, which I tried to isolate and make reproducable. The problem that occurs is that when reading lines over a pipe and do something with them, zsh stops after some lines and just hangs, while bash works w/o any problems. The following script creates a primitive directory-tree structure with a Makefile in every directory. #!/usr/bin/bash # # Usage: $0 if [ $# != 3 ] ;then echo "Usage: " exit 1 fi n=0 while [ $n -lt $3 ] ;do echo "Creating $1/$n" mkdir $1/$n echo "Hello" >$1/$n/Makefile if [ $2 -gt 1 ] ;then $0 $1/$n $[$2-1] $3 fi n=$[n+1] done # END OF SCRIPT Invoke like this: mkdir tree ./createTree.sh tree 3 3 Now, I execute this command: find tree -name Makefile | while read line ;do echo $line cp $line $line.1 done When running this under zsh, it treats between 8 and 20 Makefiles and then just hangs. (and I have to 'kill -9' the shell) Running it under bash works just fine. (or try other "4 4" instead of "3 3" when creating the tree-structure if by chance it treats all 27 Makefiles) I think this shows the fundamental problem of my make-problems as well. As long as this doesn't work, I don't even have to bother with make. Can anyone reproduce this behaviour? I'm using the latest of the greatest of cygwin on a Win2k machine. Regards, Daniel -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: zsh & make
> -Original Message- > From: cygwin-owner On Behalf Of Daniel Clausen > Sent: 27 April 2004 16:27 > When building my project with make under zsh and looking at its > build-log afterwards, I noticed that the following error occured: > > [begin error] > gmake[5]: Entering directory > `/c/work/Projects/XYZ/categories/TrxTables/unittest' > basename: too few arguments > Try `basename --help' for more information. > (last two lines repeated 8 times) > [end error] > > > We use 'basename' only in one place in the Makefiles and it looks > like this: > > COMPONENT_NAME = $(shell basename `pwd`) > Any idea how to debug this further? For debugging it, you might be able to get something useful like this: > COMPONENT_NAME = $(shell basename `pwd | tee i-was-here-.txt`) Which should at least tell you exactly how it's getting invoked. Or you could try > COMPONENT_NAME = $(shell echo basename `pwd` > command-was-this.txt && basename `pwd`) ..or any number of similar variants. cheers, DaveK -- Can't think of a witty .sigline today -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
