Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Tue, 16 Jul 2002 22:27:43 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Broken since 1.3.10, or earlier
Message-ID: <20020717022743.GA24046@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <ACEIKCIGAEOGOHGPJPIACEBLCDAA DOT DanHiggins AT austin DOT rr DOT com> <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20020716164508 DOT 02e9fc30 AT pop3 DOT cris DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20020716164508.02e9fc30@pop3.cris.com>
User-Agent: Mutt/1.3.23.1i

On Tue, Jul 16, 2002 at 05:00:38PM -0700, Randall R Schulz wrote:
>Someone who knows about the internal architecture of I/O processing in 
>Cygwin might be able to shed some light on this. If, for example, there's 
>some kind of queuing of I/O operations in Cygwin1.dll between the 
>application code (grep or a shell, in this case) and the Windows I/O 
>primitives, then there might be an opportunity for this kind of asynchrony.

Actually, AFAICT, it is a bash bug and one that I have reported earlier.

bash makes assumptions that pids grow monotonically but that is not the
case on windows.  It's possible that you can run a program twice and get
the same pid twice in a row -- especially on Windows 9x.  I try to work
around this in cygwin by keeping a certain number of process handles
open, so that the pids won't be reused, but that still causes problems
when you are fork/execing processes quickly.

What happens is that sometimes bash ends up not waiting for a process when
it should, starting the next process too early.

For instance, look at the following from an strace that shows the problem:

  881 11112361 [main] bash 1304 fork: *1288* = fork()
  979 11854415 [main] bash 1304 fork: 1120 = fork()
  895 12550685 [main] bash 1304 fork: 1648 = fork()
  947 13188885 [main] bash 1304 fork: 340 = fork()
 1103 13843029 [main] bash 1304 fork: 1484 = fork()
  950 14440217 [main] bash 1304 fork: 1560 = fork()
  880 15097448 [main] bash 1304 fork: 1144 = fork()
  931 15761062 [main] bash 1304 fork: 1620 = fork()
 1191 16484221 [main] bash 1304 fork: 864 = fork()
  902 17124502 [main] bash 1304 fork: 1548 = fork()
  825 17815402 [main] bash 1304 fork: 1280 = fork()
  968 18421987 [main] bash 1304 fork: *1288* = fork()

Guess where the output goes funny?  Right after the second fork which
results in a pid of 1288.

I "fixed" this problem in my version of cygwin by upping the number of
process handles that fork keeps open from 8 to 128.  This reduces, but
doesn't eliminate, the likelihood that bash will be confused by
repeating pids.  When I did this, I get the expected output.

This isn't really a solution, however.  It wastes resources by keeping
*a lot* of handles around so I'm not comfortable with upping the number
like this.

If you want to use this method, then run it under /bin/sh or /bin/zsh.
Neither of these programs seem to have this bug.

Oh, and as far as the "or earlier" part of cygwin goes, I tried this
back to 1.1.8.  It behaves the same way.  Of course, this wouldn't have
been a problem with B20.1 since that version of cygwin invented its own
pids rather than using windows pids.  Back then people were asking for
cygwin to use actual windows pids, of course.

>It's too bad strace cannot solve this one,

Actually strace did solve this one.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/