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 0x0000015c in ?? () #4 0xffffffff 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 <prefix> <remaining_depth> <splittingFactor> > > if [ $# != 3 ] ;then > echo "Usage: <prefix> <remaining_depth> <splittingFactor>" > 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/ > -- Peter A. Castro <[EMAIL PROTECTED]> or <[EMAIL PROTECTED]> "Cats are just autistic Dogs" -- Dr. Tony Attwood -- 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/
