Mail Archives: cygwin/2004/04/28/16:46:30
On Wed, 28 Apr 2004, Daniel Clausen wrote:
> Hi
Greetings, Daniel,
> On Tuesday, April 27, 2004, at 05:55PM, Dave Korn <dk AT artimi DOT com> 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 <doctor AT fruitbat DOT org> or <Peter DOT Castro AT oracle DOT com>
"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/
- Raw text -