Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
X-Envelope-Sender-Is:	Andrej DOT Borsenkow AT mow DOT siemens DOT ru (at relayer david.siemens.de)
From:	"Andrej Borsenkow" <Andrej DOT Borsenkow AT mow DOT siemens DOT ru>
To:	<Cygwin AT sourceware DOT cygnus DOT com>
Subject:	Strange hangups with post-1.1.4 Cygwin
Date:	Mon, 14 Aug 2000 15:19:17 +0400
Message-ID:	<000401c005e1$7c0ed060$21c9ca95@mow.siemens.ru>
MIME-Version:	1.0
X-Priority:	3 (Normal)
X-MSMail-Priority:	Normal
X-Mailer:	Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance:	Normal
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4133.2400
Note-from-DJ:	This may be spam

I noted it because Zsh regression tests suddenly started to hang. Finally I
was able to reproduce it (but still not to debug) using very simple case.
Small explanation: Zsh supports multiple IO redirectins; "foo > bar > baz"
redirects stdout into two files bar and baz. This is done by piping output of
foo to intermediate zsh process that writes it as appropriate. If foo is
builtin, the whole is actually handled internally. What happens with
post-1.1.4 Cygwin (last update today) is following:

Case 1:

zsh% print xxx > foo > bar

correctly writes both foo and bar and terminates. This happens because zsh
executes command internally as builtin.

Case 2:

zsh% ( print yyy > foo > bar )

In this case zsh is forced to run the whole in subprocess (because of parens).
Both foo and bar get correctly written to - BUT command mostly never
terminates. CPU load goes very high - judging by my CPU fan, PC is going to
fly :-) I am unable to use ^C - but ^Break magically kills running command.

Case 3:

zsh% print zzz > foo | cat > bar

In this case zsh should write into foo and pipe it's output to cat that writes
it into bar. Both files ARE correctly written, but again as in Case 2 the
whole never terminates. And again ^C does not work.

Case 4:

zsh% ( print aaa > foo | cat > bar )

In this case foo is written; bar is empty (it is created by the parent zsh
when redirection first is done) so I suspect `cat' is never even run. Again
high CPU load; again ^C does not work.

SOMETIMES at least case 2 worked. Mostly second attempt. In cases 2 and 4 I
several times got very intersting ps output (in another window):

Case 2:

mw1g017 AT MW1G17C ~
$ ps -l
    PID  PPID  PGID   WINPID  UID TTY    STIME COMMAND
   1884     1  1884     1884 1006   0 14:55:34 /usr/bin/zsh
   2400     1  2400     2400 1006   1 14:55:47 /usr/bin/bash
   2108  1884  2108     2108 1006   0 14:56:57 /usr/bin/zsh
   2000  2400  2000     2276 1006   1 14:57:13 /usr/bin/ps
   2000  2400  2000     2276 1006   1 14:57:13 /usr/bin/ps
   2000  2400  2000     2276 1006   1 14:57:13 /usr/bin/ps
   2000  2400  2000     2276 1006   1 14:57:13 /usr/bin/ps
   2000  2400  2000     2276 1006   1 14:57:13 /usr/bin/ps
    ... I had to kill it, it is actually much longer ...

In this case I have one top-level zsh, one zsh executing the whole (...)
command, bash and a single :) ps.

Case 4:

mw1g017 AT MW1G17C ~
$ ps -l
    PID  PPID  PGID   WINPID  UID TTY    STIME COMMAND
   1884     1  1884     1884 1006   0 14:55:34 /usr/bin/zsh
   2400     1  2400     2400 1006   1 14:55:47 /usr/bin/bash
   2084  1884  2084     2084 1006   0 14:58:36 /usr/bin/cat
   1804     1  2084     1804 1006   0 14:58:36 /usr/bin/zsh
   2028  2400  2028     1972 1006   1 14:59:06 /usr/bin/ps
   2028  2400  2028     1972 1006   1 14:59:06 /usr/bin/ps
   2028  2400  2028     1972 1006   1 14:59:06 /usr/bin/ps
   2028  2400  2028     1972 1006   1 14:59:06 /usr/bin/ps
   2028  2400  2028     1972 1006   1 14:59:06 /usr/bin/ps
   2028  2400  2028     1972 1006   1 14:59:06 /usr/bin/ps
   2028  2400  2028     1972 1006   1 14:59:06 /usr/bin/ps
                ... again cut down ...

-andrej

All the above seamlessly works if I exchange cygwin1.dll with that of version
1.1.4 so it looks very much like cygwin problem. Looking into ChangeLog it
seems, that the main change was exactly in process table handling. The main
reason to compile from CVS was to test some things that needed pseudo-tty
support (and did not work).

I am ready to provide any information that may be needed to debug it.

Have a nice DOS!
B >>


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -